With the introduction of Data Administration, permitted users will now have the flexibility to make database updates from the product User Interface (UI) instead of running Structured Query Language (SQL) queries from the backend. The primary purpose of the Data Administration is to empower all cloud users to independently update the database and provide a mechanism to track the history of all changes made. The key features are:

• Flexible Updates: Data Administration allows users to select and update any database table.
• Approval Mechanism: Only approved updates are applied to the database, ensuring data integrity.
• Configurable Access: Users can configure which database tables are updatable through Data Administration.
• History Log: A comprehensive history log tracks all changes made to the database using Data Administration.

Note: The Data Administration should be considered a replacement for the current method of directly accessing the database and running SQL queries. It is recommended to use this functionality only when there is no alternative available through the application UI. Ideally, the aim is to move towards a state where there is minimal usage for Data Administration.

Data Administration does not impose any restrictions, meaning there are no functional validations in place. It is intended for use only by those who are knowledgeable about how and what data should be updated. Only basic, fundamental database-level validations are supported. To effectively and safely use Data Administration, it is mandatory that users complete the certification program.

The following matrix provides the available user capabilities and their recommended assignments.

Capability Name	Capability Description	User Types
ApproveDCR	Users with this capability can approve or reject DCRs in Submitted status. Note: A user with an ApproveDCR capability, but without the CreateDCR capability, cannot modify a DCR in the submitted status.	Mfr
CreateDCR	Users with this capability can create new Data Change Requests (DCRs) and modify the existing ones that are available in Draft status.	Mfr
SetupDA	Users with this capability can access and configure Data Administration setup page.	Mfr
ViewDCR	Users with this capability can view both the DCR Summary page and the DCR Detail page, but they cannot create or approve the DCRs.	Mfr

Note: Only users with the sysadmincloud role can access Data Administration. This role grants capabilities based on the CloudDeployment property. While assigning a user with CreateDCR or ApproveDCR capability, make sure to also assign ViewDCR capability for access to Data Administration.

This extends to any kind of capability assignment, roles through UI or through prolinks (USER_ROLE, USER_CAP_MAPPING and PRO_USER_XML_IMPORT).

Capabilities can also be assigned to a user or a role using either Prolinks or Prolink XML. During the import process, set of access controls similar to those on UI screens exist ensuring that only sysadmincloud user can be assigned with DA capabilities. If the sysadmincloud capability is not assigned, the user will encounter the following error messages:

For USER_ROLE, the error message is '<name of the capability>' capability can be assigned to <sysadmincloud> user only For USER_CAP_MAPPING, the error message is '<name of the capability imported>' capability can be assigned to <sysadmincloud> user only For Pro_User_XML_import the error message is'<name of the capability imported>' capability can be assigned to <sysadmincloud> user only Note: When you see any of the above error messages, evaluate whether the sysadmincloud capability can be assigned.

Users with SetupDA capability can see and access the Data Administration Setup by navigating to System Administration > Data Administration Setup. On this page, users can see a list of all tables (including custom tables, excluding mapping tables) available in the database. Users can select the tables that should be available for updates in the Data Administration. Only the selected tables on this page will be available under the picklist in the Select & update tab of the DCR Detail page.

To make the tables unavailable, or to have them appear in the picklist field on the Select & Update tab of the DCR Detail page, follow these steps: Note: By default, all the tables except the tables related to quote, debit, POS, inventory, customer, Opp/Reg are in Unavailable status.

To make table unavailable, select the checkbox and click on Mark Unavailable action field. This will change their status from Available to Unavailable. You can also select multiple tables at once and then click on Mark Unavailable in the header. The tables marked as Unavailable will not be available in the table selection picklist field on the Select & update tab of the DCR Detail page. Note: The Data Administration Setup page displays all the tables in the database, except for mapping tables and those containing sensitive or security-related information. This restriction is implemented to prevent tampering with sensitive data. As a result, users will not find tables related to user profiles, user passwords, ADK-related data, properties, resources, system-related information, app server-related data, and logs.

The following field attributes are displayed on the Data Administration Setup page:

Field Name	Field Description
DB Table Name	Name of MN database table (Tables and Custom tables (Defined in CustomPOs property)).
Status	Indicates whether the DB table is available in Data Administration screens or not.
Refresh Icon	When the refresh icon is clicked, it retrieves the latest list of newly added tables from the database. After retrieving the tables, a message is displayed on the setup page. If any net new tables are added, the message would be: ‘Loaded <#new tables> new table(s) successfully’ or if no new tables are added, the message would be ‘No new tables available to be loaded’

All newly loaded tables will have their status set to "Unavailable" by default.

The previous configuration is saved and reapplied automatically after the refresh. For instance, if a table was previously marked as 'Available', it will retain that same status even after the refresh.

Users can begin making database updates by creating a Data Change Request (DCR). Multiple updates can be grouped within a single DCR. It is generally recommended to combine related updates into one DCR.

Users can access the DCR Summary page by navigating to System Administration > Data Administration. On this page, users can find a list of all the DCRs created along with key details about each DCR. Users can also perform the following activities based on the assigned capabilities:

• Access existing Data Change Requests
• Create new Data Change Requests

The Data Change Requests Summary page, by default, lists all the DCRs created in the Data Administration, sorted by the modified date in descending order (from most recent to oldest). Users having access to this page are able to see all Requests - either created by the logged-in user or other users.

Note: Only users with any of the CreateDCR, ApproveDCR, ViewDCR capability can view the Data Change Requests Summary page.

The following field attributes are displayed on the Data Change Requests Summary page:

Field Name	Field Description	Column Sortable (Yes/No)
DCR ID	Displays a unique alphanumeric value for a created Data Change Request (DCR). Clicking on the specific DCR link takes the user to the Data Change Request Detail page.	Yes
DCR Name	Displays the name of the DCR.	No
Description	Displays the description of the DCR if any.	No
Change Type	Displays the type of change the user intended to make in the database. The values are: Data Correction, Integration Updates, Workaround and Others.	No
Status	Displays the actual status of the request as they flow from creation to publish.	No
Effective Date	The data on which the approved updates must be published to the database. The effective date should be today or the future date.	No
Published Date	Displays the date on which the DCR changes are committed or published to the database. Note: The date is displayed only if the status is Published; otherwise, it shows '--'.	Yes
Created By	Displays the name of the user who created the request.	No
Created Date	Displays the date on which the request is created.	Yes
Modified By	Displays the name of the user who modified the request.	No
Modified Date	Displays the date on which the request is modified.	Yes

On the Data Change Requests Summary page, an Admin user with CreateDCR capability can create a new Data Change Request (DCR).

To create a new DCR, follow these steps:

Note: The mandatory fields indicated with an asterisk (*).

1. Navigate to Welcome > System Administrator > Data Administration. Data Administration page appears.
2. Click on New Change Request.
3. Type the DCR Name and Description (Optional).
4. Select the Change Type and Effective Date.
5. Select the acknowledgment checkbox.
6. Click on Save to save the new DCR. The newly created DCR will appear in draft status on the Change Request Detail page.

Once a DCR is created, users with CreateDCR capability can start making the updates on the DCR Detail page.

Note: Users with the ViewDCR capability have read-only access to the DCR Detail page and cannot perform any actions on it.

There are two ways to navigate to the DCR Detail page:

1. Navigate to System Administrator > Data Administration > New Change Request and create a new request. After saving the request, you will be taken directly to the DCR Detail page Or,

2. Navigate to Administrator > Data Administration, then click on the DCR Name of an existing DCR on the DCR Summary Page. After clicking on a DCR Name, you will be taken to the DCR Detail page.

The header contains an overview of DCR information along with the other details like history, edit and submission for approval action.

The DCR page consists of the following header information:

• DCR Name: Name provided by the user for the DCR.
• DCR ID: Unique identifier autogenerated for a DCR.
• Change Type: Type of the change the user intends to make in the database.
• Status: The current status of the DCR.
• Effective Date: The date on which the user wants the approved updates to be published or committed to the database.

On the Select & Update tab, users can select the Table from the dropdown list (this list is as per the configuration on the Data Administration Setup page), select the transaction(s) and the column(s) which needs to be updated except Modified Date and Modified By columns and edit the cell to provide the new value. Users can make multiple database updates across different tables in a single DCR. Once an update is made, user can hover on the small triangle of the updated cell to view the original value if needed.

Note: The Modified Date and Modified By columns are disabled and hence users with any level of capability cannot make changes to these columns irrespective of the DCRs' status.

• If user tries to provide an empty value to a numeric primitive data type field, then it throws an error message as Cannot accept empty value for a numeric field.
• If user tries to provide a number value beyond its precision and scale defined in the database to a number data type field, then it throws an error message as Cannot exceed the precision of <precision> and the scale of <scale>.
• If user tries to provide a string data type field with length beyond what is defined in database, then it throws an error message as Cannot exceed the maximum character limit of <max length>.
• When a data type mismatch occurs, no error message is displayed. However, if an incorrect data type field is entered, it will not be accepted, and the value will automatically revert to its original value.

All final changes or updates made in the Select & Update tab are autosaved and listed for user review. If the updates are satisfactory, users with the CreateDCR capability can submit the final changes for approval. If the updates are not satisfactory, the user can return to the Select & Update tab to make the necessary adjustments, review them again on the Review Updates tab, and then submit for approval.

All changes are grouped by table or DB table name. By default, the changes are collapsed. Expand each table to review the changes under it.

The number in the brackets beside the Review Updates tab represents the total number of final updates in that DCR. The number in the brackets beside each table represents the total number of final updates made in that table.

From the Columns and Filters options, you can select or un-select the set of columns for which you want to see the information on the DCR Detail page in both the Select & Update tab and Review Updates tab.

From the Filters option, users can filter the requests based on the columns listed on the Data Change Requests Summary page. For fields description, refer to Access Existing Data Change Requests.

Note: Filters in Select & update tab will work based on original values and not the updated values.

For example, let's consider a scenario where you are working with table named Quote, which contains columns for OID, Created Date, and End Customer OID and their original values are:

OID	Created Date	End Customer OID
1	28/08/2024	625

Now, let’s update the above values as:

OID	Created Date	End Customer OID
1	29/08/2024	1000

Now, apply filters on end customer oid with ‘1000', it shows empty results; however, if you enter filter with original value as '625’, it shows the record with updated value as 1000.

OID	Created Date	End Customer OID
1	29/08/2024	1000

From the  Columns  option, users can select or un-select the set of columns for which they want to see the information on the Data Change Requests Summary page. For fields description, refer to Access Existing Data Change Requests.

When making updates in a DCR, users may need to work with a specific set of records and use filters to narrow down their view. To streamline this process, especially if the same filters are needed for multiple changes, there is an option to save the filters for easy reuse.

Some guidelines while using saved filters in Data Administration.

Select & Update tab:

• Saved filters saved in the Select & Update tab are specific to this tab and table
• Saved filters created are available only to the user who created it
• Saved filters get adjusted based on table selection
• Default filters are specific to each table and should be applied automatically when that table is selected Note: There can only be one default saved filter per table.
• Saved filters retains both the selected columns and filters
• Saved filters are specific to each DCR throughout its lifecycle and even after publishing
• Deleting a saved filter will remove only the associated table

Review Updates tab:

• Saved filters saved in this Review updates tab are specific to this tab
• Saved filters created are available only to the user who created it
• Saved filters retains both the selected columns and filters
• Default filters are for the entire Review Updates tab and should be applied automatically when that table is selected Note: There can only be one default saved filter for this tab.
• Saved filters are specific to each DCR throughout its lifecycle and even after publishing
• Deleting a saved filter will remove only the associated table

Users with CreateDCR capability can submit a DCR in draft status for approval. Additionally, they can update various fields before submitting a DCR for approval. For more information on updating or editing DCR, refer to Editing/Updating a DCR. Note: Once the DCR reaches Submitted status, it can no longer be edited by CreateDCR capability users.

To submit DCR for approval, follow these steps:

1. Navigate to the DCR Summary page.
2. Click and open any existing DCR that is in draft status or continue to the next step in the newly created DCR.
3. As explained in the Select & Update section, make necessary updates in Select & Update tab, finalize all the updates by going to Review Updates tab. DCR details entered during creation, can also be updated by clicking on Edit button. For more information on updating or editing DCR, refer to Editing/Updating a DCR.
4. Once you are done with making all the updates, click on Submit for Approval button.

After the DCR is submitted for approval, the following steps occur automatically:

1. DCR status gets updated from Draft to Submitted.
2. An email notification and an alert on application are sent to the ApproveDCR capability user prompting them to take action.
3. Once the DCR reaches Submitted status, it can no longer be edited by CreateDCR or ApproveDCR capability users.
4. The Edit button changes to View. This prevents any further changes from being made to the DCR Detail page by Requester user.

Users with ApproverDCR capability can take action on a submitted DCR either by approving using Approve button or rejecting with the Reject button.

There are two ways to approve or reject a submitted DCR:

• From Notification/Alert
• From DCR Summary page

To approve or reject a DCR, follow these steps:

1. Once a DCR is submitted for approval, an ApproveDCR capability user receives an email notification and an alert.
2. Click on Alert icon on the Home page of the application or email inbox.
3. Click on ‘Click here for more info’ hyperlink, to directly navigate you to the respective DCR Detail page or, navigate to the DCR Summary page and then click and open the required DCR that is in Submitted status.
4. All the updates submitted by the CreateDCR capability user are summarized under Review updates tab.
5. If all the updates are satisfactory, the submitted DCR can be approved by clicking on Approve button. A confirmation pop-up message is displayed to acknowledge the changes before being approved.
6. Select the acknowledgment checkbox and click Yes. This ensures that all the updates submitted in that DCR are approved.
7. If any updates are unsatisfactory, the submitted DCR can be rejected by clicking on Reject button. This ensures that all updates submitted in that DCR are rejected. Note: You can approve or reject the entire DCR. You cannot approve or reject an individual updates submitted within a DCR.
8. If you think certain updates are incorrect or missing, and you have both CreateDCR and ApproveDCR capabilities, you can go to the Select & update tab to make the necessary changes. These updates will then appear in the Review updates tab. In this case, you do not need to resubmit the DCR for approval; you can directly approve or reject the updated DCR.

After the DCR is approved or rejected, the following steps occur automatically:

1. DCR status gets updated from Submitted to either Approved or Rejected based on the DCR is approved or rejected.
2. An email notification and an alert on application are sent to the CreateDCR capability user.
3. Once the DCR reaches Approved status, it can no longer be edited by CreateDCR capability users.
4. The Edit button changes to View. This prevents any further changes from being made to the DCR Detail page by Approver user.

The general details of a DCR entered during its creation can be updated or edited by using the Edit button on the DCR Detail page. To update or edit an existing DCR, follow these steps:

1. Navigate to the DCR Summary page.
2. On the DCR Summary page, select the DCR Name of the existing DCR.
3. Click on Edit.
4. Change the required details and click on Save.

Out of the Box (OOB), a job is scheduled to run every 24 hours, which automatically commits all the updates in an approved DCR to the database as per the effective date mentioned in the DCR. This job publishes all the DCRs to the database which are approved and whose effective date is today or today+1 or in the past. Note: There is no need to configure or set up this job, as it is automatically created by the system and scheduled to run daily at 11:30 PM (as per customer default time zone).

In addition to the OOB job, if a user wants to immediately commit DCR updates to the database without waiting for the job that runs daily at 11:30 PM (as per customer default time zone), user can follow the below mentioned steps:

1. Navigate to System Administration > Scheduled Event Summary and create a Schedule Job of type Run Backend Task and task as Publish Approved DCRs. For more information on creating and scheduling the job, refer to Creating a Job Definition and Creating a Job Schedule.
2. In the ListOfDcrIds field, enter the DCR IDs you want to publish, separated by commas. You can enter as many DCR IDs as needed. If this field is left blank, the job will publish all approved DCRs with effective dates in the past, today, or today+1. Note: if DCR IDs are entered manually, as long as they are approved, they will be approved irrespective of their effective dates.
3. Run the job to publish the required DCRs to the database immediately.
4. If the job successfully publishes a DCR, its status changes from Approved to Published. If the job fails to publish a DCR, its status changes from Approved to Publish Failed.

Note: If a DCR is failed, job doesn’t stop but continues to publish remaining DCRs provided in the job.

After the DCR is published, the following steps occur automatically:

1. DCR status gets updated from Approved to Published.
2. The database stores the newly published changes.
3. The Modified Date column is updated to display the system date when the job is executed.
4. The Modified By column is updated in the format:<DCR ID> - <DCR name>.
5. History log records the published changes.
6. An email notification and an alert on application are sent to the CreateDCR capability user.
7. Once the DCR reaches Published status, it can no longer be edited by any capability users.
8. The Edit button changes to View. This prevents any further changes from being made to the DCR Detail page by any user.

If the job contains multiple DCRs with mix of approved and non-approved statuses, the system will publish the approved DCRs without interruption and skip those with other statuses. The history log will record the reason for skipping the DCR as <DCR ID (Seperated by commas)>-DCR is not approved.

If the job contains multiple DCR but the entered id does not exist, then it skips that DCR. The history log will record the reason for skipping the DCR as <DCR ID (Seperated by commas)>-DCR doesn’t exist.

If the job has DCR that has already been published or Publish failed, the job will fail to publish that DCR. The history log will record the reason for failure of that DCR as DCR already published/Already Publish Failed.

If the job contains DCR IDs that are all approved, they can be published regardless of their effective dates.

During the lifecycle of a DCR, several email notifications and alerts are sent to relevant users, starting from its creation to publication. As the DCR moves from one status to another, different users are notified about status changes and prompt them to take necessary actions on the DCR.

NOTE: Email notifications and alerts will be automatically (OOB) sent to users without the need for any configuration setup.

To view the alerts or notifications, click Alert icon on the Home page of the application or email inbox. When the user clicks on the hyperlink, they will be taken directly to the respective DCR Detail page.

Related to Data Administration, history is logged at two places in RC application:

• Data Data Administration level
• Business Object (BO) level

The history log for the Data Change Request page captures all updates that are made to the DCR from creation till it is published. History log is logged whenever an action is performed by the user in the DCR with details like who performed the action, when was the action performed, what is the action and what is the update.

1. Navigate System Administrator > Data Administration.
2. Click on specific DCR you want to see the history details for.
3. Click on History. This opens a history log window that captures all the updates or changes happened in a DCR.

The following changes are captured in the history log for:

• DCR Creation: <DCR ID> is Created
• DCR name updated from ‘<old value>’ to ‘<new value>’
• Description updated from ‘<old value>’ to ‘<new value>’
• Change Type updated from ‘<old value>’ to ‘<new value>’
• Effective Date updated from ‘<old value>’ to ‘<new value>’
• Changes to tables columns: Updated from ‘<x>’ to '<y>’ or ‘<_>’ to '<y>’
• Changes Submitted: <DCR ID> status is changed from ‘Draft’ to ‘Submitted’
• Changes Approved/rejected: <DCR ID> status is changed from ‘Submitted’ to ‘Approved/Rejected'
• Changes Published/publish failed: <DCR ID> status is changed from ‘Approved’ to ‘Published/DCR publish failed'

The following filters are available for users to view the history log as required:

• When: To filter by the time when the change was made
• Who: To filter by the user that made the change
• Table Name: To filter by the name of the table
• Transaction OID: To filter by the Transaction OID
• Column Name: To filter by the column name
• Description: To filter by the description of the action done

History is logged at BO level screens, only when the DCRs are published successfully. If changes or updates occur in a BO related to a table, the history will also be recorded in the respective screens of that BO. For example, if updates happen in the Quote table, the quote screen’s history log will include changes made through Data Administration. History log at BO level will log the details like who performed the action, when was the action performed and what is the update. Note: Currently, history is only logged for BOs that already have history logging enabled in the application.

1. Navigate to the respective BO application screen.
2. Click on specific transaction you want to see the history details for.
3. Click on History Log. This opens a history log window that captures all the updates or changes happened at a BO level.

The following updates are captured in the history log for:

• DCRxxx - <DCR name>
• Table: <Table name> Column: <column name> changed from ‘<x>’ to '<y>’