Overview

nCino is the worldwide leader in cloud banking. In today's competitive landscape, customer and employee expectations are changing. Speed, convenience, and trust matter most. To meet these expectations, financial institutions must leverage the right technology to provide the personalized experience customers and employees demand.

With its Bank Operating System, built on the Salesforce platform, financial institutions can deliver the speed and digital experience that customers expect, backed by the quality and transparency that bankers need.

Why did nCino choose AutoRABIT?

AutoRABIT is designed around the industry’s only CI/CD (Continuous Integration / Continuous Delivery) server purposely built for Salesforce to handle metadata and data. AutoRABIT delivers an integrated suite of tools including version control, deployment automation, sandbox management, data migration, and test automation. This streamlines processes and automates activities at each stage of the DevOps lifecycle, simplifying deployment from development to production.

With AutoRABIT's strong expertise with Salesforce technology, working together with nCino extends CRM clients directly into a streamlined processing system. AR collaboration with nCino helps lending institutions stay ahead of today's complex deployment challenges and retool their business to succeed in the next era of banking.

Before You Begin

Before you start working with the nCino features in AutoRABIT, you need to configure certain things in AutoRABIT to proceed:

1. Register the nCino configured Salesforce Org in ARM.

2. The Super Admin should categorize the account type as appropriate subscription to create either a Standard or Community Template.

3. Users are allowed to access the Feature Migration section. The Admin can assign the required permissions to users by visiting the Admin > Roles tab and creating a role with the permissions below enabled.

4. You should only be able to edit/modify your existing CI job if the special permissions for CI Job List are assigned to you. For ex- To edit or delete your existing job, you need Edit and Delete permissions.

Super Admin roles in Account Activation and Categorization (Partner/Customer)

The Super Administrator will have the capability of marking an account as either partner/customer with the user-specific prefix. The accounts marked as a partner will be able to create Standard/ Community templates whereas customer accounts are restricted to creating only community templates.

Simply, login to the AutoRABIT account using the Super Admin credentials and go to the My Account section. Under the Subscription Details, assign the user as an nCino Partner to allow them to create Standard/Community Templates. If not assigned, the user will be treated as a customer account and are restricted to creating only Community templates.

Registering nCino configured Version Control Repository

1. Go to the Version Control Repo tab and click on Register Repository.

1. On the next screen, select your Version Control System.

2. Fill in the registration page with necessary details such as repository name, URL, master branch, etc.

3. Tick the checkbox: Enable nCino

4. Click on the Test Connection button to check whether the connection has been authenticated or not. A success message is displayed after the authentication is completed.

5. Click Save to complete the registration process.

Registering nCino configured Salesforce Org

1. Go to the SF Org Mgmt. tab and click on the Add button.

1. On the next screen, give your Salesforce Org a Name and select your Salesforce Org Type and Environment.

2. Select the authentication method in the Access Type dropdown.

3. Select the checkbox- Is nCino Installed

4. Click Validate and Save to proceed through the OAuth flow and allow AutoRABIT to connect to your Salesforce Org.

Overview

This details the step-by-step process to create a standard/community nCino migration template.

Procedure

1. Hover your mouse over the nCino module and click on the option: Feature Management.

1. Click on New Feature Migration Template button.

1. On the next screen, click Create New to create a fresh template and include objects of your choice.

1. You'll be taken to the record-based configuration section, where you will find three tabs that need completed to proceed ahead:

   • Metadata Configuration

   • Record Configuration and

   • Preview and Save

Metadata Configuration

You need to provide basic information on this tab to create a feature migration template.

Under Feature Details, enter the items below:

1. Name: Provide a feature migration template name.

2. Associated Partner: The default associate partner would be nCino, which you can change if necessary.

3. Version: Enter the version number here. If you're creating the feature template for the first time, it is recommended to keep the version number as 1.0.

Under the Salesforce Org Details section, do the following:

1. Choose your Salesforce Org.

2. Click Fetch Objects to retrieve all available objects in the selected Source Org.

3. By default, only nCino objects available in the Source Org will be auto-populated. To view all the objects available, click on Show All Objects.

4. Using/button, you can select/deselect all the objects for your template. Or, use the Ctrl key and select multiple objects of your choice and move them to the selected tab using/button. Once you have selected the object, ARM will retrieve the fields included in that object behind the scenes.

1. Click on Next to go to the Record Configuration Tab.

Record Configuration

This tab is where you apply filters for the entry objects. Also, on the left side of the screen, you can see the list of items that are segregated into:

1. Selected List: This will include a list of all objects that are part of your selected template and objects that you have chosen to add later on.

2. Related List: This section will only be displayed in the Attachment Object as your migration template feature is included.

3. Required List: This contains mandatory objects which you cannot exclude,

4. Excluded List: This section lists non-required data objects you could permanently exclude while creating a template so that the template does not contain data object information. Some of the objects are auto-selected depending on the selected template, and you have the option to de-select them as well.

Based on the relationship between the objects, the AutoRABIT application will segregate the object sets, and applying a filter to each bucket is mandatory. By default, AutoRABIT will denote an object in a bucket as an entry point, which can be applied filter. This is not mandatory, but as a best practice, AutoRABIT recommends applying filters to the entry point object rather than any other object.

The entry object is selected by default, and the user can apply a filter. The entry object is denoted by “E”.

Applying the Filters

Apply the filter(s) using the steps as shown below:

Click Add.

The filter query is added and displayed in the filter box. You can edit the query if any modification is required. Nevertheless, multiple queries can be added based on your requirements. Validate your query to see whether the query entered is stable. Additionally, you'll be able to view several records that will get fetched.

You can also use the Query Editor to execute a SOQL query on the selected Source Org. Results are displayed in a Query Results grid.

Similar steps are to be followed for objects in other buckets as well.

Once done, click Next to proceed to the Preview and Save screen.

Preview and Save

This is the summary page for the Feature Migration template you're about to create. You can view the features details, and filters you have applied for the last time before the template is created. Any change log information that needs to be added can be mentioned in the Change Log box.

Click Save, and you will be redirected to the Feature Migration Summary screen, where you can track your template recently created.

Overview

This article deals with the step-by-step procedure to create a standard/community template by picking a feature with nCino predefined objects.

Procedure

1. Hover your mouse over the nCino module and click on the option: Feature Management.

1. Click on New Feature Migration Template button.

1. Choose one of the features from the list. For example, select the Spreads Schedule Template tile to include the Spreads Schedules feature predefined objects in a template.

1. You'll be navigated to Record Based Configuration section, where you will find three tabs that need to fill in to proceed ahead:

   • Metadata Configuration

   • Record Configuration and

   • Preview and Save

Metadata Configuration

To create a feature migration template, you must provide basic details on this tab.

Under Feature Details section, fill in the below details:

1. Name: Provide a feature migration template name.

2. Associated Partner: The default associate partner would be nCino, which you can change if necessary.

3. Version: Enter the version number here. If you're creating the feature template for the first time, it is recommended to keep the version number as 1.0.

Under the Salesforce Org Details section, do the following:

1. Choose your Salesforce Org.

2. Click Fetch Objects to retrieve all available objects in the selected source org. Predefined objects will be auto chosen based on your selected feature. By default, only nCino objects available in the source org will get auto-populated. To view all the objects available, click on Show All objects.

3. Using/button, you can select/deselect all the objects for your template. Or, use the Ctrl key and select multiple objects of your choice and move them to the selected tab using/button. Once you have selected the object, ARM will retrieve the fields included in that object behind the scenes.

1. Click Next to go to the Record Configuration tab.

Record Configuration

This tab is where you apply filters for the entry objects. Also, on the left side of the screen, you can see the list of items that are segregated into:

1. Selected List: This will include a list of all objects that are part of your selected template and objects that you have chosen to add later.

2. Related List: This section will only be displayed in the Attachment Object for your migration template feature is included.

3. Required List: This contains mandatory objects, and you cannot exclude them,

4. Excluded List: This section lists non-required data objects you could permanently exclude while creating a template so that the template does not contain data object information. Depending on the selected template, some objects are auto-selected, and you can deselect them.

Based on the object's relationship, the AutoRABIT application will segregate the object sets, and applying a filter on each bucket is mandatory. By default, AutoRABIT will denote an object in a bucket as an entry point, which can be applied filter. This is not mandatory, but as a best practice, AutoRABIT recommends applying filters to the entry point object rather than any other object.

The entry object is selected by default, and the user can apply a filter. The entry object is denoted by “E”.

Applying the Filters

Apply the filter(s) using the steps as shown below:

Click Add. The filter query gets added and gets displayed in the filter box. You can edit the query if any modification is required. Nevertheless, multiple queries can be added based on your requirement. Validate your query to see if the query entered is stable or not. Additionally, you'll be able to view several records that will get fetched.

You can also use the Query Editor to execute a SOQL query on the selected source org. Results are displayed in a Query Results grid.

Similar steps are to be followed for objects in other buckets as well. Once done, click Next to proceed to the Preview and Save screen.

Preview and Save

This is the summary page for the feature migration template you're about to create. You can view the features details, and filters you have applied for the last time before the template is created. Any change log information that needs to be added can be mentioned in the Change Log box.

Click Save, and you will be redirected to the Feature Migration Summary screen, where you can track your template recently created.

Overview

The Feature Migration History page lists all the standard or community templates that are created to date.

The Community tab contains those templates that are either in progress or yet to be published (Ready-Draft). Once it is published, the template moves from the Community to the Standard Tab and is ready for customers to use.

On this page, you can:

1. View the template created in chronological order.

2. See the status of the template.

3. Review the latest version of the template.

4. Check the time/date stamp of the template last modified.

5. Observe the last template used.

6. Audit the change log details.

7. Evaluate the dataset: View the list of records that were fetched and download the records locally (if required).

8. Manage your template.

Viewing Dataset

Clicking on the View Dataset button will allow you to see the list of records that were fetched. You can view them either in JSON view or TREE view. There is also a provision to download both metadata and data objects list to your local machine. The file is downloaded in ZIP format.

Manage Template

Click on the Manage call-to-action button to make necessary changes to your created template or get the template published.

Additional Options on the 'Manage Template' screen

1. Create Version: The user can create a new version for the already created Feature Migration template.

2. Publish the template: To allow all the nCino customers to access the template, the nCino partner needs to officially publish it. Upon confirmation, the status of the template changes from Ready-Draft to Ready-Published. The template can now be found under the Standard tab.

3. Actions:

   • View DataSet: You may now view the list of records fetched separately for each version you create. Prior to the ARM 22.2 release, you could only see the records for the most recent version. With this release, the feature is enhanced for each version created.

   

   

   • Clone Version: The Clone Version option quickly generates a new version using information from the existing template.

   • Version Log: Version Log maintains records of all notable changes made to the template.

   • Change Log: Document the change log data for each version.

   • Delete Template: Use the icon to delete the template. This process cannot be undone.

This article will walk you through deploying nCino data using the Feature Migration template. If you're referring to this article for the first time, please navigate to Feature Migration Template, which deals with the step-by-step procedure of creating a fresh migration template in AutoRABIT.

1. Hover your mouse over the nCino module and click on the Deployment History option.

1. Click on the Feature Deployment button.

1. On the next screen, give the process a name and a brief description.

2. In the Source section, select Deployment From as Template.

3. Select the template Feature Type, i.e., Standard or Community Template.

4. Select your template and its version of it.

5. Based on your template selection, the object configuration section will render the selected objects and apply filters and mappings.

1. Choose your destination environment. It can be your target salesforce org or commit to your version control branch.

2. To deploy into a Salesforce Org, select the Deploy To checkbox and choose your Destination Org. To commit to a branch, select the Commit To box, enter your Repository/Branch details, and comment (if any).

1. There are various options that you can configure to your objects before you proceed with deployment or commit:

   • Applied Mappings

   • Sorting (only if the 'commit' checkbox is selected)

   • Applied Filters

   

Applied Mappings

In this section, you can use an external ID in place of a related record's Salesforce record ID to relate or associate records to each other as you process an Upsert operation. For example, if Object B has a lookup field to another Object A, you can use the values contained in a field that's marked as an External ID on Object A to relate the two (Object B to Object A records).

• In the Source field: Select your source field whose values will be populated in the destination External Id field.

• In the Destination field: Select the required field from the destination org whose values will remain unique for all the records.

Sorting

This new feature allows you to sort fields for nCino objects while committing. Based on the sorting order set, the record order in the JSON files will get fetched. The users will be provided a default sorting order that can be changed. XXXXX_lookupkey__c is the most preferred field for sorting, and that would be the default field. If this field is not present, the Name for custom settings and Id for non-custom settings would be selected.

For the objects with sorting fields opted, the sorting icon gets changed.

Applied Filters

Such filters will be displayed here if any filter is applied to the objects.

Deployment Option

Based on your destination selection, you will have different deployment buttons to choose from:

• Deploy: Deploying to the salesforce org only

• Commit: Committing to the version control branch only

• Commit & Deploy: Committing and deployment together.

For deploying to the destination org, you will find the list of deployment criteria you can opt for before proceeding.

Deployment Filters

1. Disable Workflow Rules: This option will deactivate the workflow rules associated with objects part of the deployment.

2. Disable Validation Rules: This option will deactivate the validation rules associated with objects part of the deployment.

3. Use Bulk API (Batch API will be used if the option is not enabled): You can transfer bulk records in a go from the source and destination org.

4. Insert/update with Null Values: This will either insert or update record field values with null in the destination org (if the value is null in the source org).

5. Use UTF-8 file encoding for file read and write operations: Use UTF-8 as the internal representation of strings. Text is transcoded from the local encoding to UTF-8 when data is written to or read from a file. UTF-8 must be enabled if your data exclusively contains English alphabets. UTF-8 must be disabled if your data contains non-English alphabets. UTF-8 should be enabled by default in accordance with Salesforce.

Click OK to complete the feature deployment process.

You'll be redirected to the following:

• Commit History page if you have opted for the commit process to run.

• Feature Deployment Summary page if you have opted for deployment. It is where you can view detailed deployment reports or re-deploy the nCino objects to your salesforce org/version control once again.

This section is all about deploying the nCino data via the salesforce org dataset.

1. Hover your mouse over the nCino module and click on the Deployment History option.

1. Click on the Feature Deployment button.

1. On the next screen, give the process a name and a brief description.

2. In the SOURCE section, select Deployment From as Template using Salesforce Org.

3. Select the template Feature Type i.e, Standard or Community Template.

4. Select your Template and its Version of it.

5. Select your Source Salesforce Org.

6. The object configuration section will render the selected objects and apply filters and mappings based on your template selection.

1. Choose your Destination Environment. It can be your target salesforce org or commit to your version control branch.

2. To deploy into a salesforce org, select the Deploy To checkbox and choose your Destination Org. To commit to a branch, select the Commit To box, enter your Repository/Branch details, and comment (if any).

1. There are various options that you can configure to your objects before you proceed with deployment or commit:

   • Applied Mappings

   • Sorting (only if the 'Commit to' checkbox is selected)

   • Applied Filters

   

Applied Mappings

In this section, you can use an external ID in place of a related record's Salesforce record ID to relate or associate records to each other as you process an Upsert operation. For example, if Object B has a lookup field to another Object A, you can use the values in a field marked as an External ID on Object A to relate the two (Object B to Object A records).

• In the Source field: Select your source field whose values will be populated in the destination External Id field.

• In the Destination field: Select the required field from the destination org whose values will remain unique for all the records.

Sorting

This new feature allows you to sort fields for nCino objects while committing. Based on the sorting order set, the record order in the JSON files will get fetched. The users will be provided a default sorting order that can be changed. XXXXX_lookupkey__c is the most preferred field for sorting, and that would be the default field. If this field is not present, the Name for custom settings and Id for non-custom settings would be selected.

For the objects with sorting fields opted, the sorting icon gets changed.

Applied Filters

Such filters will be displayed here if any filter is applied to the objects. You can edit the already applied filter (if required) using Edit Filter.

Deployment Option

Based on your destination selection, you will have different deployment buttons to choose from:

1. Create Dataset: Create a dataset from your Salesforce Org

2. Create Dataset & Deploy: Create a dataset and deploy it to your Salesforce Org

3. Create Dataset & Commit: Create a dataset and commit to a Version Control Branch

4. Create Dataset Commit & Deploy: Create a dataset and proceed for both commit and deployment.

For deploying to the destination org, you will find the list of deployment criteria you can opt for before proceeding.

Deployment Filters

1. Disable Workflow Rules: This option will deactivate the workflow rules associated with objects part of the deployment

2. Disable Validation Rules: This option will deactivate the validation rules associated with objects part of the deployment

3. Use Bulk API (Batch API will be used if the option is not enabled): You can transfer bulk records in a go from the source and destination org

4. Insert/update with Null Values: This will either insert or update record field values with null in the destination org (if the value is null in the source org)

5. Use UTF-8 file encoding for file read and write operations: Use UTF-8 as the internal representation of strings. Text is transcoded from the local encoding to UTF-8 when data is written to or read from a file. UTF-8 must be enabled if your data exclusively contains English alphabets. UTF-8 must be disabled if your data contains non-English alphabets. UTF-8 should be enabled by default in accordance with Salesforce.

Click OK to complete the feature deployment process.

You'll be redirected to the Feature Deployment Summary page, where you can view detailed deployment reports or re-deploy the nCino objects to your Salesforce Org/Version Control once again.

This section is all about deploying the nCino data using Version Control

1. Hover your mouse over the nCino module and click on the Deployment History option.

1. Click on the Feature Deployment button.

1. On the next screen, give the process a name and a brief description.

2. In the SOURCE section, select Deployment From as 'Version Control.'

3. Select your version control type.

4. Select your repository and branch.

5. Select the deployment type. There are three options to choose from:

   • Entire Branch: This option will fetch the feature migration templates configured on your branch. You'll be asked to choose the template and version when selecting the entire branch option.

   

   • Single Revision: This option will pull all of the versions from your repo, allowing you to choose which revision to use in the deployment.

   

   

   • Revision Range: This option allows you to specify a commit range from which the revisions are to be deployed.

   
6. The object configuration section will render the selected objects and apply filters and mappings based on your selection.

1. Choose your target org.

1. There are various options that you can configure to your objects before you proceed with deployment:

   • Applied Mappings

   • Applied Filters

   

Applied Mapping

In this section, you can use an external ID in place of a related record's Salesforce record ID to relate or associate records to each other as you process an Upsert operation. For example, if Object B has a lookup field to another Object A, you can use the values in a field marked as an External ID on Object A to relate the two (Object B to Object A records).

In the Source field: Select your source field whose values will be populated in the destination External Id field.

In the Destination field: Select the required field from the destination org whose values will remain unique for all the records.

Applied Filters

Such filters will be displayed here if any filter is applied to the objects.

Click on Deploy to proceed to the next screen. The next screen will display the list of deployment criteria that you can opt for before proceeding with deployment.

Deployment Settings

1. Disable Workflow Rules: This option will deactivate the workflow rules associated with objects part of the deployment

2. Disable Validation Rules: This option will deactivate the validation rules associated with objects part of the deployment

3. Use Bulk API (Batch API will be used if the option is not enabled): You can transfer bulk records in a go from the source and destination org.

4. Insert/update with Null Values: This will either insert or update record field values with null (if the value is null in source org) in destination org.

5. Use UTF-8 file encoding for file read and write operations: Use UTF-8 as the internal representation of strings. Text is transcoded from the local encoding to UTF-8 when data is written to or read from a file. UTF-8 must be enabled if your data exclusively contains English alphabets. UTF-8 must be disabled if your data contains non-English alphabets. UTF-8 should be enabled by default in accordance with Salesforce.

Click OK to complete the feature deployment process.

You'll be redirected to the Feature Deployment Summary screen, where you can view detailed deployment reports or re-deploy the nCino objects to your Salesforce Org once again.

This section is about deploying the nCino metadata and data via version control using the Salesforce dataset.

1. Hover your mouse over the nCino module and click on the Deployment History option.

1. Click on the Feature Deployment button.

1. On the next screen, give the process a name and a brief description of it.

2. In the Source section, select Deployment From as Version Control using Salesforce Org.

3. Select your Version Control type, Repository, and Branch.

4. Select the deployment type.

   • Entire Branch: This option will fetch the feature migration templates configured on your branch. You'll be asked to choose the template and template version when you select the entire branch option.

   

   • Single Revision: This option will pull all of the versions from your repo, allowing you to choose which revision to use in the deployment.

   

   
5. Select your Source Salesforce Org.

6. Based on your template selection, the object configuration section will render the selected objects and apply filters and mappings.

1. Choose your Destination Environment.

1. There are various options that you can configure to your objects before you proceed with deployment or commit:

   • Applied Mappings

   • Applied Filters

   

Applied Mappings

In this section, you can use an external ID in place of a related record's Salesforce record ID to relate or associate records to each other as you process an Upsert operation. For example, if Object B has a lookup field to another Object A you can use the values contained in a field that's marked as an External ID on Object A to relate the two (Object B to Object A records).

In the Source field: Select your own source field whose values will get populated in the destination External Id field.

In the Destination field: Select the required field from the destination org whose values will remain unique for all the records.

Applied Filters

Such filters will be displayed here if any filter is applied to the objects. You can edit the already applied filter (if required) using Edit Filter.

Deployment Option

Based on your destination selection, you will have different deployment buttons to choose from:

1. Create Dataset: Create a dataset from your Salesforce Org. On selection, you will be redirected to the Commits History screen.

2. Create Dataset & Deploy: Create a dataset and deploy it to your Salesforce Org.

For deploying to the destination org, you will find the list of deployment criteria you can opt for before proceeding.

Deployment Filters

1. Disable Workflow Rules: This option will deactivate the workflow rules associated with objects part of the deployment

2. Disable Validation Rules: This option will deactivate the validation rules associated with objects part of the deployment

3. Use Bulk API (Batch API will be used if the option is not enabled): You can transfer bulk records in a go from the source and destination org

4. Insert/update with Null Values: This will either insert or update record field values with null (if the value is null in Source Org) in Destination Org

5. Use UTF-8 file encoding for file read and write operations: Use UTF-8 as the internal representation of strings. Text is transcoded from the local encoding to UTF-8 when data is written to or read from a file. UTF-8 must be enabled if your data exclusively contains English alphabets. UTF-8 must be disabled if your data contains non-English alphabets. UTF-8 should be enabled by default in accordance with Salesforce.

Click OK to complete the feature deployment process. You'll be redirected to the Feature Deployment Summary page, where you can view detailed deployment reports or re-deploy the nCino objects to your Salesforce Org once again.

Feature Deployment

Feature Deployment is a deployment process that will allow you to easily deploy both metadata and data components using the feature migration template or using the dataset configured either from your Salesforce Org or Version Control.

Feature Deployment History

The Feature Deployment History lists every deployment you have previously run using AutoRABIT. It is also where you can view detailed deployment reports or re-deploy the nCino objects to your Salesforce Org/ Version Control.

Accessing Feature Deployment History Page

You can visit ncino > Deployment History to view the Feature Deployment summary page or you'll be auto-redirected to this page whenever you trigger a deployment (using Feature Deployment).

By default, the jobs are listed in reverse chronological order; that is, the most recent job shows up first. Deployment history is shared amongst team members in AutoRABIT, so you may see deployments performed by other members of your team.

My Deployments tab lists all of the deployment operations you have performed. The Others tab will list all other deployments made in AutoRABIT by your team.

Navigating Feature Deployment History

For each deployment, the following information is displayed:

1. Deployment label: The deployment label name. You can search for deployments by label name using the search filter in the top right of the page

2. Feature Name: Feature name assigned to the deployment

3. Status: Successful, Failed, Partially Failed, or In progress

4. Deployment Version: Version number for the deployment

5. Source: The source Salesforce Org

6. Date: The date and time of the deployment

7. Owner: Which user performed the deployment

8. Iteration: The number of revisions for your deployment; for dataset deployments, the iteration number will appear as "dataset"

9. Destination: Target salesforce org

10. Redeploy: Redeploy will allow you to re-trigger the deployment process again [Refer to "Re-trigger the Deployment" section on this page]

Filtering Deployment History

You can search for items in your history using the search box in the top right of the page.

You can view all deployments (default), or only successful, failed, partially failed, in-progress or timeout deployments, or filter results by deployment label, feature name, the owner who carried out the deployment, or between to/fro dates.

To filter the deployment via Feature Name, you will have the versions list auto-populated to fetch the exact result.

Data Retrieval Workspace

Deployments will be in the queue for dataset refresh jobs and will be displayed under Data Retrieval Workspace.

Applicable only if the deployment is carried via:

1. Template using Version Control

2. Version Control using Salesforce Org

Viewing the Deployment Summary

Click on one of the Labels to view the detailed deployment summary info.

Feature Template- Revision Details

For each template revision, you can find the list of all data nCino objects that were either deployed or failed. View the individual object deployment details by clicking on the object or view the success or failed count directly.

Object Information: Click on the object to view their detailed information on the right side of the page.

Retrieved: This section will tell you the total records that are being retrieved. You can even download the records on your local machine. The file format is downloaded in CSV format.

Success: Now, the selected records can be downloaded using the download option. Click on the success record count.

Click on “Success Count” for the pop-up to appear. A download option will be available for you to select. Click on the download option for the records to be downloaded. You will see the ‘.csv’ file being downloaded.

Failed: The failed records can be downloaded using the download option available. Click on the failure count for the pop-up to open. Use the ‘Download’ button on the pop-up to download the failed records.

Deployment Log

View individual deployment steps that are carried out under the Deployment Log section. Each deployment has a number of "steps", which contain a subset of logs, such logs can be seen here. You can either view compete log information in the user interface or save it to your local machine using icon. The file usually gets downloaded in ZIP format.

Re-triggering the Deployment

Once you have fixed the deployment error or you like to re-trigger the deployment once again, you can click on the Re-Deploy button to quickly restart your deployment.

Choose the 'Destination Org' and the deployment criteria you want to set for the deployment process.

Once the deployment is re-triggered, a new iteration gets auto-generated with new deployment log details. If the deployment gets failed due to any metadata or data objects, such a report can be found on this page.

The Feature Commit History will list down all the commits that occurred during the feature migration deployment operation along with the commit logs details and the list of objects that were committed to your version control system.

Navigate to nCino > Commit History.

The left side of the screen will display the complete list of commits that happened.

Using the Advanced Search filter, you can filter any specific commit records faster.

Next, click on one of the commit labels to view its detailed information on the right side of the screen. You can find the commit details such as commit label, commit status, author username, date and time of the commit performed, etc.

Revision Info

This section will list down the objects that were either newly added to the version control system or were updated to the existing objects.

• A denotes object was newly added

• M denotes object was modified or updated

Click onicon to view the complete list of metadata and data added or modified.

If you would like to download the changes report, simply click on Download Report () icon. The report will get downloaded to your local machine. To go back to the main screen, click on the back button on the top left corner of the screen.

Commit History Log

This section will list down the step-by-step log details for your commits.

Overview

ARM facilitates the creation of CI jobs, allowing users to migrate or deploy nCino data and metadata into their destination environments using the following ways:

Prerequisites

Before you proceed with CI job creation, you must have the below permissions:

1. You're allowed to access the CI Jobs section. The admin can assign the required permission to you by visiting the Admin > Roles tab and creating a role with the above permission enabled.

2. To create a CI job, you must have Create CI Job permission. The admin can assign the same by visiting the Admin > Roles tab and creating a role with the above permission enabled.

3. You should be able to edit/modify your existing CI job only if special permission for CI Job List is assigned.

For example, you will need Edit and Delete permissions to edit or delete your existing job.

Creating a CI Job

1. Log in to your AutoRABIT account.

2. Hover your mouse over the nCino module and click on CI Jobs.

3. Click on Create CI Job, available on the top corner of the screen.

4. On the next screen, give the job a descriptive name in the Job Name field and briefly describe it.

5. Next, you must choose the appropriate deployment method for your CI job configuration.

   

   • Deployment via template: You'll be asked to choose the template type, i.e., standard or community. The data which is part of the standard or community template chosen will be picked up and deployed to the destination org or selected version control.

   

   • Deployment via template using Salesforce Org: The object configuration, such as filters, applied mappings, and so on, will be picked up from the standard/community template chosen. Based on the configurations, the data is pulled from the source org and later deployed to the destination environment.

   

   • Deploment via Version Control: Select the template which is part of the version control branch. Such data is pulled from the version control and deployed to the destination.

   
6. You can choose from three additional deployment types when you select the Deployment From Version Controloption.

   • Entire Branch: All of the templates from the version control branch will be populated, and you can choose any of them or all.

     
   • Baseline Revision: The nCino revisions are pulled from the version control branch, and you must select one from the list. All the revisions above the set baseline revision will be picked up, which implies the templates committed above the baseline revision will be picked up, and you can deploy those templates to the target org. For example, if you want to include templates from the top three versions, you must select the fourth revision as the baseline revision.

   

   • Revision Range: The templates are picked up based on the from and to revisions, and you can deploy those templates to the destination org.

   

   • Deployment via Version Control using Salesforce Org:The object configuration, such as filters, applied mappings, and so on, will be picked up from the standard/community template chosen, which is part of version control. Based on the configurations, the data is pulled from the source org and later deployed to the destination environment.

   
7. Select the template(s) from the populated templates list for the CI job process. Click on the template, select the template version. Repeat the step for more template selection. Use the Select All checkbox to select all the templates for deployment to be carried out. The template chosen will get listed under the Selected Versions tab.

1. Use the up/down arrow button to move the selected versions up and down or the delete button to remove a version from the list. Based on the selection, the top version will be deployed initially, and the process continues for the remaining versions.

1. Click Next to proceed to the next screen.

2. Choose your destination environment.

   • Destination Org: Select your target org to which the templates will get deployed.

   • Version Control: Select your repository and branch to commit the templates.

   

1. Under Object Configuration, view the objects available for your selected templates. Click on the + sign will render the object list and the applied mappings and filters for each template version.

1. Applied Mapping: The application will default use AutoRABIT external ID for record mapping between source and destination org. Users will have the option to choose their own external ID based on the requirement. LookupKey__c is auto-chosen as a default field. If the lookupKey__c field is unavailable, AutorabitExtId__c would be the next choice, and similarly, Name will be the third preference if both lookupKey__c and AutorabitExtId__c are unavailable.

   • In the 'Source' field, you must select the source field whose values will be populated in the destination external Id field.

   • In the 'Destination' field, you must select the required field from the destination org, whose values will remain unique for all the records.

   
2. Applied Filters: If any filter is applied to the objects, such a filter will be displayed here. You can edit the applied filter (if required) using the Edit icon. Editing of the filter is currently not allowed for deployment via the template.

1. Click Next to proceed to the next screen.

2. Under the Notifications section, select the user email id to send email notifications on the success or failure of a build. Use the Add User Email (s) button to add the custom email address of the users to get notified of the CI job pass or fail.

1. Next, under the Schedule section, you can schedule the process it must run.

   • Daily: The process will run daily at the scheduled time or interval set.

   • Weekly: The process will run weekly on the scheduled day and time.

   • No schedule: The process will only be saved; you can run it when required.

   
2. Select other destination orgs under the Post Deployment Activities section. This will allow the package from the build to be reused to deploy the same data in various Salesforce environments as a post-deployment successful activity.

1. Click Next to proceed to the final screen. This is the summary page for the CI job that you're about to create. You can view the template details and the mappings/ filters you applied for the last time before the job gets created.

1. Before you conclude, select the criteria that you can set for the deployment process to continue.

   • Disable Workflow Rules: This option will deactivate the workflow rules associated with objects in the deployment.

   • Disable Validation Rules: This option will deactivate the validation rules associated with objects as part of the deployment.

   • Use Bulk API (Batch API will be used if the option is not enabled): You can transfer bulk records from the source and destination org.

   • Insert/update with Null Values: This will either insert or update record field values with null (if the value is null in source org) in destination org.

   • Use UTF-8 file encoding for file read and write operations: Use UTF-8 as the internal representation of strings. Text is transcoded from the local encoding to UTF-8 when data is written to or read from a file. UTF-8 must be enabled if your data exclusively contains English alphabets. UTF-8 must be disabled if your data contains non-English alphabets. UTF-8 should be enabled by default as per Salesforce.

   
2. Click Save to complete the job creation process. You'll be redirected to the CI Result screen, where you can trigger a build for your configured job to run the CI operation. Select your CI job from the dropdown on the top right corner of the CI Results screen and click the Build Now button to trigger a build for your recently created job.

Overview

The CI Job Results screen will display the list of builds triggered for your CI Jobs to date. In addition, you can even trigger a new build or find detailed build info for your existing jobs, such as build status, log reports, author details, etc.

Navigating to CI Job Result Screen

1. Hover your mouse over the nCino module and click on CI Jobs.

2. By default, you will be redirected to the Job Results tab; if not, click on the Job Results tab. The list of CI job builds will display in reverse chronological order; the newest will display on the top of the list.

Trigger a Build

To trigger a new build for your CI Job, follow the below steps:

1. From the CI Job Results screen, select your job from the All Jobs dropdown field. The dropdown here allows switching between the CI Jobs created.

1. If no build is created yet, 'No builds exist' gets displayed, or if the build is already triggered for the job and you wish to trigger another build, click on Build Now besides your selected job.

1. The left side on the next screen will have summary details of your CI job configured, i,e., job label, source/destination org, deployment method chosen, etc.

1. Under the Build inputs section, enter the title of the build and add comments, if any.

2. Choose the Deployment Type:

   • Commit and Deploy: Both commit and deployment will undergo if chosen

   • Deploy only: Deployment happens to the selected destination org only.

   • Commit only: Committing the changes to the version control branch only.

3. Add any additional information in the Notes section. However, this is optional.

4. Click on Trigger Build. It will validate the user credentials, and the build will get triggered upon successful validation.

1. You'll be redirected to the Job Results main screen, where you can find your recently triggered build status.

Build Log and Object detail

1. From the CI Job Results screen, click on the CI Job from the list to view the build details or use the All Jobs drop-down to look for your job.

or,

1. From the list of build lists triggered, look for the build for which you want to see the log and object details. Click on the build once you found it.

1. For each template deployed, the Data tab will list all the nCino objects committed or deployed, along with the success/fail count.

1. Click on the object to view its detailed object information displayed on the right side of the screen.

1. The number of records successfully deployed or failed to deploy can be seen under the Success/ Failed tab.

To view the detailed object records that were successfully deployed or failed to deploy, click on the number link (under Success or Failed).

1. The Log tab contains the detailed report of the commit/deployment performed. Each commit/deployment has several "steps," which contain a subset of logs; such logs can be seen here. You can view complete log information in the user interface or save it to your local machine usingicon. The file usually gets downloaded in ZIP format.

1. Post-Deployment Activities: The post-deployment activities information is displayed on this tab. If you have selected more than one Salesforce org as your destination, select the respective org from the Salesforce Org drop-down to view the detailed success/failure objects count.

Download Backup Snapshot

Introduction

Now it's easy to download the backup snapshot of the CI Jobs as required. You can go to the respective CI job and download the backups of the templates all at once or individually.

Step-by-Step Guide

1. Go to any CI Job.

2. Click on any template available under the build.

1. On the template page, you will see the download option available for each object.

1. Open the CI Job, then hover over the three dots at the far right of the banner as shown below.

1. Click on the “Build Changes” option.

2. You will be redirected to a “Build Changes” page.

1. On the “Build Changes” page, click on the “Download” button to download all the templates from that build.

2. You can see the files downloaded.

Commit and Deployment Workspace

Commit Workspace: When various commits are deployed to a branch, the queue commits will be mentioned here. The main concept of introducing the commit workspace is to allow parallel commits to the same version control repository/branch.

Deployment Workspace: View the ongoing deployment process by clicking on the Deployment Workspace icon on the right side of the page.

CI Job Results 'Advanced Search' Filter

1. Filter by Job Name/ Build Number: Filter the builds by CI job label name and the build number.

2. Triggered By: Filter the builds by the author.

3. Filter by Created/ Modified Date: If you want to view job lists that get authored between any two dates, use the 'From Date' and 'To Date' to narrow down the list of build lists.

4. Filter by Build Label Name: Filter the builds by build label name.

5. Filter by Build Status: Filter the list based on build status, i.e., success or failed.

6. Filter by Deploy Status: Filter the build via deployment type, i.e., commit and deploy or deploy or commit.

The CI Job List screen displays all the jobs created to date, and the lists are in order of the last created/modified date.

Various options on the 'Job List' screen:

1. Info (): View the detailed report for your CI job.

2. Clone (): Quickly create a new job using information from the existing job.

3. Edit/Delete CI Job: To modify/update or delete a CI Job from your history, click either the Edit () or Delete () icon.

CI Job List Advanced Search Filter

1. Filter by Job Name: Filter the job list by CI job label name.

2. Filter by Created/ Modified By: Filter the job list by an author who created or modified the CI job.

3. Filter by Created/ Modified Date: If you want to view job lists that get authored between any two dates, use the 'From Date' and 'To Date' to narrow down the list of the job lists.

Webhooks for Auto Triggering nCino CI Jobs

Refer to Webhooks for configuration details. Currently, nCino supports the following webhooks:

1. Webhook for GitHub

2. Webhook for GitHub Enterprise

3. Webhook for Microsoft Azure

4. Webhook for GitLab

5. Webhook for Bitbucket

6. Webhook for Bitbucket Enterprise

7. Webhook for Visual Studio GIT

8. Webhook for Visual Studio GIT Enterprise

For the above-mentioned repositories, if you select “Trigger Build on Auto-Commit,” the job will be triggered automatically for every new commit to the branch.

Configuring the CI Job for Trigger Build on Commit

1. Toggle the slider in the highlighted selection to enable 'Trigger Build on Commit' for the respective job.

1. Observe the copy symbol beside the URL. Use the highlighted URL as 'payload URL' in the configuration settings of the webhook. Refer to the following page for help configuring the webhook.

2. Once a job is created with the 'Trigger Build on Commit' setting enabled, then every commit into the respective repository and branch will auto-trigger a run in the application.

Using Supported Deployment Types

For the Revision Range deployment type, the TriggerBuildOnCommit option is not supported, which is expected behavior. When using a defined "From" and "To" revision, the system has no new revisions to detect or upon which to trigger builds. As a result, TriggerBuildOnCommit functionality does not apply to Revision Range deployments.

Supported Deployment Types for TriggerBuildOnCommit

The TriggerBuildOnCommit option is available for the following deployment types only:

1. Version Control with Baseline Revision: Suitable for deployments requiring specific baseline comparison.

2. Entire Branch: Triggers on new commits to the entire branch, allowing continuous integration.

3. Version Control using Salesforce: Integrates directly with version control but uses Salesforce to detect and trigger builds on commits.

If your deployment uses Revision Range, TriggerBuildOnCommit will not apply. If triggering builds on commits is required for your workflow, consider using one of the supported deployment types listed above.

Manually Committing Templates

To manually commit the template data into your version control system (outside of AutoRABIT), follow the steps below:

Information to collect before committing:

• HEXID: A random 8-character alphanumeric string, for example: 10cPkE0E

• Feature-Org-Id: Provided by AutoRABIT upon request, for example: rJA5XMqsT71C6AwhaA7jyHznMxXvpRSM

Steps to Commit New Templates:

1. Add the HEXID and Feature-Org-Id details in the following files (refer to the attached sample file for guidance):

   • feature-templates/nCino/config/manifest.yaml

   • feature-templates/nCino/config/project-def.json

2. Create a feature folder named using the format hexId-featureName and include all relevant details such as filters, data, object sets, buckets, object relationships, and user IDs.

3. Ensure all information follows the folder structure of the reference folder.

4. Add ar-config/project-def.json file at root folder as in the attached reference.

Steps to Modify Existing Templates:

1. For any record additions, deletions, or updates, make the necessary changes under:

   • feature-templates/nCino/dataset/hexId-FeatureName/data

2. To modify object filters, make adjustments under:

   • feature-templates/nCino/dataset/hexId-FeatureName/filters

Introduction

Using this feature, users can perform the deployments to the Orgs selected on the post-deployment activities.

Feature Overview

1. When creating the configuration, users can select multiple Orgs (max 5 allowed) for post-deployment activities.

2. This feature eliminates the necessity for performing multiple deployments to each individual Org if the same template(s) is required to be deployed to multiple Orgs.

Step-by-Step Guide

1. Users can select multiple Orgs, as shown on the screenshot below, to deploy to while creating the config for CI Jobs.

1. Once the Job is created, users can open the job created.

1. Click on the ‘Build Now’ button to trigger the build.

1. Upon completion of the CI Job deployment, the post-deployment activities will be triggered, as shown in the following figure.

1. While the post-deployment activities are being deployed, the post-deployment activities will be shown in progress, as seen in the prior screenshot.

2. Upon successful deployment, the relevant status is shown under the ‘Post Deploy Details’ section.

3. As shown in the following screenshot, users can click on the ‘View Details’ section to further verify post-deployment activities.

1. The post-deployment Org details can also be verified by clicking open the build, as shown below.

1. Upon opening the deployed build, the post-deployment Org details can be observed as listed below:

   • Click on the ‘Post Deployment Activities’ tab.

   • Click on the ‘Salesforce Org’ dropdown to see details for the Org deployed to.

   • Click on the ‘Notes’ icon to see the logs of ‘Post Deployment Activities.’

   

Introduction

Now users can seamlessly specify the baseline revision from a set of revisions available from the repository.

Feature Overview

1. Users can select the baseline revision from which the system can select all the revisions available until that date as part of the deployment.

2. Once a user specifies a the baseline revision, the system will automatically pick up all the commits available from that point forward, every time a deployment is triggered on that job.

Step-by-Step Guide

1. Select the ‘Version Control’ in the ‘Deployment From’ field of the ‘CI Job’ creation screen.

1. Select ‘Baseline Revision’ in the ‘Deployment Type’ field as shown in the following screenshot.

1. Select ‘Git’ in the ‘Version Control’ field as shown in the following screenshot.

1. Select the required repository from the list in the ‘Repository’ field, as shown in the following screenshot.

1. Select the ‘Branch’ to which users can deploy through the ‘Branch’ field available.

1. Select the required revision from the list available in the ‘Revision’ field, as shown in the following screenshot.

1. Open the ‘Revision’ field by clicking on the search icon. Upon clicking the search icon, a popup opens up, as shown in the following screenshot.

1. Select the required commit as a baseline revision and click ‘ok’ to confirm. When you complete the selection, the selected commit is displayed on the field.

1. Upon clicking ‘Save’ on the ‘CI Jobs’ configuration, users will be redirected to the ‘Job List’ section of the ‘CI Jobs’ page, as shown below.

1. Upon clicking the ‘Play’ button, users are taken to the ‘New Build’ page, where users can ‘Trigger Build’ using the button.

   • On the ‘New Build’ screen, users can view the ‘Baseline Revision’ selected, under the ‘Baseline Revision’, as shown below.

   

Introduction

Now it is easier to select a range of revisions through Version Control.

Feature Overview

This feature allows users to select a range of commits from the available commits for that deployment.

Step-by-Step Guide

1. Select ‘Version Control’ from the ‘Deployment From’ field.

1. Select ‘Revision Range’ from the ‘Deployment Type’ field.

1. Select ‘Git’ from the ‘Version Control’ field.

1. Select the required repository from the ‘Repository’ field.

1. Select the required ‘Branch’ from the ‘Branch’ field.

1. Select a revision in the ‘From Revision’ field.

1. Select a revision from the ‘To Revision’ field.

1. Revisions that are available below the one selected in the ‘From Revision’ field, will remain grayed out for the rest of the selection.

1. After the required revisions are selected, continue with the configuration of the CI Job creation.

2. Once the required configuration is selected, click ‘Save’ on the ‘Preview & Save’ section of the ‘CI Job’ creation screen.

1. Once ‘Save’ is clicked, users are redirected to the ‘CI Job’ list page.

1. Click on the ‘Play’ button to trigger the build. Upon clicking the ‘Play’ button, users are redirected to the following page.

Introduction

Rollbacks are an indispensable pillar in the realm of systems that undergo continuous evolution. They provide a safety net, enabling you to revert to a known, stable state if something goes wrong.

Feature Overview

This feature allows users to perform a rollback of the deployments—if rollbacks were enabled when creating the deployments.

Feature Considerations

To be able to perform rollbacks on the deployments, users must mark the deployments for rollback when configuring deployments.

Step-by-Step Guide

1. Log in to your ARM account.

1. Go to the nCino module.

2. Rollbacks can either be performed through CI Jobs or Feature Deployment.

CI Job Rollback

1. Once in the nCino module, click on the 'Create CI Job' button.

1. Enter the required information to configure the CI Job creation.

2. In the Preview and Save section, users can toggle the button to enable the rollback option.

1. Initially, the slider is disabled. Users must toggle the button to turn on the 'Enable rollback' option, as shown in the following picture.

1. On enabling the 'Enable rollback' option, users can continue to 'Save' the job.

2. While enabling the 'Enable rollback' option, users can click on the question mark and read the message: “Please note that the data of this rollback will be retained for a period of 30 days and will be deleted as the retention period elapses.”

3. Upon saving the job, users are directed to the 'Job List' page as shown.

1. On landing on the 'Job List' page, users can continue and run the job they created by clicking on the ‘play’ icon.

1. Once the build run is completed, users can see that the 'rollback' button is available on the 'job results' page.

1. When the build is completed successfully, users can download the snapshot of the backed-up data by hovering on the list icon beside the 'Rollback' button in the 'Job Details' page, as highlighted in the following screenshot.

1. Users can initiate the rollback from the 'Job Results' page directly or the 'Details' page.

2. Users can see the 'Rollback' button in the following screenshot on the 'Job Details' page.

1. Upon clicking the ‘Rollback’ button, users are prompted to decide whether to go ahead with the 'Rollback’ operation as shown in the image below.

1. As the 'Rollback' build is in progress, the page looks like the following:

1. Once the 'Rollback' is completed successfully, the 'Job Details' page looks like the following:

1. A new build will be added to the list of the build in the following format: 'Rollback' - < Build No >

2. Users can roll back the builds as often as needed.

Feature Deployment

1. Initiate a 'Feature Deployment' by clicking on the 'Feature Deployment' button.

2. Continue to input the ‘Source’ and ‘Destination’ configuration details.

3. On entering all the required details, click on the 'Create Dataset & Deploy' button.

4. On clicking the 'Create Dataset & Deploy' button, a popup with the 'Enable Rollback' option is displayed.

5. Select the checkbox to enable the rollback of this deployment.

1. Users can see an information icon beside the 'Enable Rollback' button that says, “Please note that the data of this rollback will be retained for a period of 30 days and will be deleted as the retention period elapses.”

1. Until the deployment is completed, it is not possible to perform a 'Rollback' on the deployment.

2. Click the 'Deploy' button to deploy the build.

1. Only upon completion of the deployment is the 'Rollback' option available.

Observe the ‘Rollback’ option, both on the 'Deployment History' page and on the 'Job Details' page.

1. Once the deployment is finished, users can download the backup snapshot of the deployment marked for ‘Rollback.’

1. Click on the 'Rollback' button to roll back the deployment.

2. Once the 'Rollback' is completed, then the iteration number will be updated.

3. While the 'Rollback' is in progress, the 'Re-Deploy' and 'Rollback' buttons are grayed out until its completion.

1. Observe the ‘Rollback’ iteration in the logs by expanding the deployed build, as shown below.

Rollback – Post Deployment Activities

Rollback functionality is now supported for the Orgs selected for post-deployment activities. Please choose the selected Orgs in the highlighted section of the CI job creation flow.

Additional Resources

What happens during the rollback of the deployments on the destination Org?

1. Insert: The inserted records in the destination Org are deleted.

2. Update: Updates to the destination Org are reverted to their original state.

Comprehensive reference for integrating with AutoRABIT API endpoints

Endpoint Overview

AutoRABIT API endpoints are listed below.

Continuous (CI) Jobs

Retrieve the CI build / job details, trigger new job, and view different CI job reports.

/api/cijobs/v1/ncino/getAllProjects

/api/cijobs/v1/ncino/jobHistory

/api/cijobs/v1/ncino/triggerBuild

/api/cijobs/v1/ncino/ciJobBuildSummary

/api/cijobs/v1/ncino/getcijobinfo

/api/cijobs/v1/ncino/ciJobBuildHistory

/api/cijobs/v1/ncino/pollStatus

Looking for more information on ARM Developer APIs or ARM API References? Perhaps you wanted this section here.

Introduction

Compare and selective deployment functionality allows you to perform compare operations on different datasets and from various objects across the Orgs and promote the selected/required records to further environments.

Overview

1. Compare functionality enables you to perform the Org-to-Org comparison and Org-to-VC comparison.

2. You can perform the relational compare operation on the initial dataset retrieved from the initial compare operation performed.

3. At each level of the compare operation, you can perform the individual selection of the records retrieved from both the initial compare and the relational comparison operation.

4. The records selected at different levels of the compare operation can be saved and you can continue with further selection.

5. Once you are done with record selection, you can continue with the deployment by clicking on the “Save and Deploy” button.

6. On the object summary screen, you can review the records selected on the compare screen(s) and continue with RBC deployments.

Step-by-Step Guide

Initiating Compare Operation

Feature Deployment – Template & Version Control

1. On selecting the “Template” OR “Version Control”, you will see the “Retrieve Dataset” option.

2. On clicking the “Retrieve Dataset” option, you will land on the “Deployment History” page.

3. On “Deployment History” page, for the deployment being done, you will have the “View Dataset” option. Clicking on this option, will open the dataset.

Feature Deployment – Template/VC Using Salesforce ORG

1. Select “Template Using Salesforce Org/VC Using Salesforce Org” to see “Create Dataset” visible.

2. Click on the “Create Dataset” option to continue performing the ‘compare’ operation after you are taken to the “Deployment History” page.

Perform Compare

1. Open the deployment, then click on the “Compare” button..

1. Once you click on “Compare,” a pop-up will be shown.

2. The compare operation can be performed as either “Org to Org” or “Version Control.”

Org-to-Org Comparison

Select the ‘Salesforce Org’ radio button to perform an Org-to-Org comparison.

Org-to-VC Comparison

Select the ‘Version Control’ radio button to perform the Org-to-VC comparison.

Compare Results

1. Perform either the Org-to-Org or Org-to-VC compare operation.

1. On this screen, you can alter the destination as required.

2. You can select from the following fields on the compare screen:

   • Destination

   • Feature Name

   • Object

   • Unique ID

   • Exclude From Compare

3. Upon completing the required selections, click on the “Compare” button on the pop-up.

4. You can see the results on the “Compare Results” screen.

5. Across the compare results screen, the differences between ORGs, which are otherwise called as changes are highlighted in yellow on the “destination ORG value”.

   • Differences in record values are highlighted at the relational compare level as well.

1. Object: You can select one object at a time for comparison against the destination.

2. Unique ID: You can select one Unique ID at a time from the drop-down.

3. Exclude From Compare: This multi select checkbox allows the users to select the required fields to be excluded from the comparison.

Note: The user can perform “Compare” operation each time, for change in the object, and for the respective selections.

• Fields excluded from compare are represented in a light gray color on the grid. Observe the following screenshot for reference.

1. Select: Through this dropdown, you can select either of the options “Select the Current Page Records” or “Select All Records”.

2. You can search through the data from the compare operation using the:

   • Search By Field: User can select the field to search.

   • Value: User must enter the value to search for.

NOTE: - The columns Select, View Records, LLC_BI_lookupKey_c and Name would be the default fields on the grid.

1. The first 25 fields from the compare result set retrieved from the compare operation are shown in the table view under “Compare Results.”

2. Excluded From Compare: Users can open the link and verify the fields excluded from the compare.

3. Export: The compare results can be exported to Excel through either of these options:

   • Records on the page: This will export the records on the current page to Excel.

   • All Records: This will export all the records retrieved from the compare operation.

1. Change View: You can click open the ‘Change View’ link and add/remove the fields to be displayed on the compare results grid.

   • Only 25 fields are displayed on the grid at any given point of time.

   • Fields excluded from compare are highlighted in a gray hue on the change view screen.

1. View Record: Is useful for viewing the entire record from source and destination at one place.

   • Click on the “View Record” icon highlighted below to view the record value from both source and destination.

   • Click on the “View Record” icon to view the pop-up with record details from ‘Source & Destination’.

1. Save And Continue: You can click on this to perform the “selective deployment”.

2. Save And Deploy: Click on ‘OK’ to continue with the deployment(s). You will be taken to the deployment page with the selected records displayed.

NOTE: A count of the selected records is shown on the “Object Summary” screen, while the user is being redirected to the deployment page.

1. On Clicking “Save and Deploy,” you can view the object summary of all the records selected.

1. Once the user clicks on the “Save and Deploy” button, you will be redirected to the deployment page with the “Iteration – Staging”.

1. Clicking on the total under “Selected Records” will show you the record(s) in a pop-up.

1. Click on “Deploy” to perform the deployment of the selected records.

2. On successful deployment, the iteration will be changed to “1” and users can see Success and Failure records.

1. You can see the “Success” and “Failure” results of the deployments.

Relational Compare - Global & Record-Level

Global Relational Compare

This will compare the selected object with the object in the destination and identify and highlight the related parent and child records.

1. Clicking on the relational compare icon beside the column “Related Records” will display a pop-up.

   • This will perform a global-level relational compare operation on all the records that are retrieved as part of the initial compare operation.

1. You can make a selection on parent and child sections:

   • Object: Select the required items from the list of objects for comparison

   • Unique ID: Select the unique ID from the list.

2. Exclude From Compare: Select the records to be excluded from the compare operation.

3. Click on the Compare icon to initiate the compare operation.

4. On completing the comparison, the identified records will be highlighted.

Record-Level Relational Compare:

1. Click on the record-level relational compare icon to perform the relational compare operation.

1. You can make the respective selection(s) on parent and child sections:

   • Object: Select the required object from the list of objects for comparison

   • Unique ID: Select the unique id from the available list.

   • Exclude From Compare: Select the records to be excluded from the compare operation.

   • Click on the compare icon to initiate the compare operation

   • Upon completing the compare operation, you will be taken to the “Level 1” relational compare results page.

     • You can continue to perform the relational compare operation to the ‘nth’ level or indefinitely.

2. View Records: You can see the details of the record on which the record-level comparison is performed.

3. You can both collapse and expand the “Relational Parent” and “Relational Child” sections, as observed above.

   1. The “Relational Parent” and “Relational Child” sections are collapsed for the convenience of viewing.

4. As shown below, you can perform the relational comparison at different levels.

5. You can perform the ‘Global Relational Compare’ and the ‘Record Level Comparison’ at these levels too, as displayed in the below screenshot.

6. You can continue to select from the set of records that are extracted from the compare operation.

7. On concluding the records selection, the user can either,

   • Save and Continue: Save the initial record selections and continue to select other records to perform relational compare operations.

   • Save and Deploy: Saves the current selection of records and navigate you to the deployment page, where the selected records can be deployed to further environments.

8. Please observe the “Object Summary” for reviewing the selected records.

9. By clicking on the total displayed under the “Selected Records”, you can view the records in a pop-up.

10. Once the user clicks on the “Save and Deploy” button, you will be redirected to the deployment page with the “Iteration – Staging.”

11. Click on the “Deploy” button to perform the deployment of the selected records.

12. On successful deployment of the records, the Iteration will be changed to “1” and you can observe success and failed records.

13. Once the deployment is done, you can observe the “Success” & “Failed” counts of the deployed records on the above screen.

Exclude the OwnerID from Automapping in nCino CI jobs

To ensure user permissions differences between different environments will not affect the RBC deployments, users are provisioned to disable the auto assignment of users as they trigger the RBC deployments.

By default, the option is disabled, which signifies that the user permissions will be auto-assigned if another user continues to trigger a job that was initiated by a different user in another environment.

While triggering the RBC configuration deployment, you must explicitly disable the option to make sure that the users will not be auto-mapped.

Introduction

Now users no longer have to worry about the possibility of 'External Unique ID’ being assigned to non-unique fields.

Feature Overview

1. As part of this feature, a validation will be performed to verify whether the ‘lookup key’ is available in the destination Org.

2. A verification will be performed to confirm whether users have access to the ‘External ID’.

3. If the external unique ID is changed to a ‘non-unique field’ (example: Name), then a notification will appear when users click on the ‘Create Dataset & Deploy’ or ‘Create Dataset Commit & Deploy’ button.

Step-by-Step Guide

1. Select the required values from the dropdown available on the ‘Feature Deployment’ section.

2. If the ‘external ID’ is not available, then the following notification as highlighted will be displayed in the popup, when users click on ‘Create Dataset & Deploy’, as displayed in the following screenshot.

Select External Unique Identifier During nCino Feature Deployment

This provision allows you to go through the list of external unique IDs available and will allow you to select the external unique ID of your choice.

1. By default, the ID, Name, and a unique field will be populated in the dropdown.

2. If the name is auto generated, then that name will not be considered a unique field.

The external unique ID field is available in the “Deploy” page.

If the source for the deployment is a CSV file, then all the fields will be displayed in the dropdowns.