nCino

Record-Based Migration error use case

Description: The user was deploying nCino records using the nCino standard template from the source environment to the destination environment.

Problem Statements:

1. ARM not picking up the Parent route look up value on the Route group object, thereby resulting in empty parent routes in the destination org.

2. Blank lookup fields that were recently updated from not null to null are not being updated by ARM.

Resolution:

1. The parent object must also be included in the deployment for the child object's lookup fields' values to be updated.

2. Deploying both Route and Route Group objects while choosing the "Insert/update with null values" option will update the Parent Route lookup field with a null value.

Other Queries:

a. How exactly does ARM go about retrieving datasets?

Preparing object sets (from child to parent) that reflect relationships between the chosen objects is the first step in the dataset retrieval process. Next, pull the data of the object on which the filter is applied (entry object). After then, ARM begins processing sets object by object, starting with the object sets that contain the entry object.

b. Why is the nForce_Route_c object auto-selected on the Record Configuration screen?

For the standard templates, ARM has a default entry object defined by the nCino team. So when trying to create a template from a standard tile, ARM auto-select that default object and indicate "E" to denote it as an entry object. If you are trying to create a new one via the New + icon, the first object will be auto-selected. This is the reason why the nForce_Route_c object is auto-selected in the below screen.

c. To pull all required data from parent and child objects, why apply a filter on the child object?

In this current scenario, when Route and Route Group are selected, as per our process, we don prepare object sets first, and below are the object sets prepared. Group object is automatically picked since Route Group has a Master-detail relationship with Group.

Object Set 1: nFORCE__Route_Group__c, nFORCE__Route__c

Object Set 2: nFORCE__Route_Group__c, nFORCE__Group__c

• What if the filter is applied on Route Group?

  First, we pull data from Route Group based on the filter, and then as per the set-1, we will pull relations of Route with the help of the below query.

  Select nFORCE__Route__c,nFORCE__Parent_Route__c from nFORCE__Route_Group__c where Id is (route group id's based on filter applied) Next, if self-references exist on Route, we do retrieve those relations. In the same way, we do process set-2.

• What if the filter is applied on Route?

  First, we pull data from Route based on the filter, and then as per the set-1, we will pull relations of Route Group with the help of the below queries.

  Select Id from nFORCE__Route_Group__c where nFORCE__Parent_Route__c in (route id's based on filter applied) Select Id from nFORCE__Route_Group__c where nFORCE__Route__c in (route id's based on filter applied) Next, if self-references exist on Route Group, we do retrieve those relations. In the same way, we do process set-2.

In the second case, if Route Group has any other Route via the nFORCE__Parent_Route__c field other than the route that is picked as a part of the query applied, that will not be considered. But in case one, we do consider data from both nFORCE__Route__c and nFORCE__Parent_Route__c fields.

So, in the case of custom configuration, the best practice is to apply a filter on the child object. Exceptional Scenario: Now, I would like to highlight here one more exceptional case where you need to have a look at considering the entry object when the below objects are part of your customized scenario. No matter whether it is parent relation or child relation, as per the nCino design, data for the objects on the right side have to be pulled only based on objects on the left side. So when your scenario includes any of the below object pairs, the filter has to be applied on left-side objects.

How to send custom label translations from one nCino environment to another

To select the language translations and for you to view them in the list, they need to be enabled under your source salesforce org first. Follow the below steps to perform the translation deployments:

• Under source Salesforce org, go to Setup > Translation Workbench > Translation Language Settings and enable the appropriate language.

• Once enabled, go to ARM and try to retrieve the components under Translations. You will observe the languages populated.

• Create a new deployment by selecting the custom object translations, its relevant languages under translations, and the custom object. Your target environment should have custom label translations now.

Please refer to the article: Working with Translation in ARM for more detailed information.

Conditional rendering references in the 'Screen' sections are not included when using the nCino standard UI template

The views and the self-references screens sections were not picked up during the feature deployment using the nCino standard UI migration template. This is our top priority, and our development team is working hard to remedy the problem as quickly as possible. After running the nCino UI migration template, please run the Screen UI template to pick up all the missing components as a workaround.