Edit

Salesforce Org Management

Important Note: This article is for the Org Administrator in particular. The actions discussed in the article will not be available to general users.

Overview

All the org connections added to ARM can be seen on the Salesforce Org Management page. This page lists details for the Salesforce orgs you have added and any org that has been shared with you by your team members.

The Salesforce Org Management page shows information about:

  1. Details of your Salesforce org

  2. ALM / Plugins mapped with your Salesforce org

  3. List of metadata members available with your Salesforce org

  4. Default Apex Test Class configured

  5. User Permissions assigned to your Salesforce org

Salesforce Org - Details

A summary of the Salesforce org registered with ARM is displayed in this area.

The fields displayed in this section are described in the table below:

Field Name
Indicates

Name

Name of the Salesforce org given when registering with ARM.

Type

Salesforce org types such as Developer, Sandbox, or Production.

Environment

Your Salesforce environment, i.e., Production or Development Edition, Sandbox, or Production.

URL

Salesforce login URL.

Registered Date

Date of account activation.

Access Type

Authorization type such as OAuth, Standard. For the Standard Access type, the username, password, and security token will be displayed.

Re-Authenticate

If the OAuth token has expired for a saved connection, click this to re-enter your user credentials and refresh the connection so ARM can continue to connect to it.

Test Connection

To check if the connection has been authenticated or not. Once clicked, a success message is displayed once the authentication is complete.

Person Accounts Enabled

When you do business with individual consumers, you can enable the Person Accounts. Person accounts apply to organizations that operate on a business-to-consumer model. Remember that you cannot disable Person Accounts once you enable them. For more information, refer to the article published in Salesforce: https://help.salesforce.com/articleView?id=account_person_enable.htm&type=5

nCino Package Enabled

This checkbox is selected by default if your Salesforce org is enabled with nCino objects. Unselecting the checkbox will remove the nCino objects configured with your Salesforce Org, and you'll be unable to use the nCino metadata and data for deployment.

About nCino Package Enabled: Selecting the Enable nCino package previously required getting all nCino deployed packages of the Salesforce org; however, users without Modify All Data and Download App permissions could not register the org in the ARM application. To avoid this, the mandatory option to load nCino deployed packages while registering a Salesforce org has been disabled.

Additional options under 'Salesforce Org - Details' section

  1. Clone: ARM clone functionality creates duplicate records to reduce unnecessary retyping.

  2. View/Download Audit Log: The audit log shows the recent changes made to your org. It lists the date of the change, who made it, and what the change was. All objects include fields to store the name of the user who created the record and who last modified the record. This provides some basic auditing information. Use the Download Audit Log button to save the audit log in your local system.

  3. Generate Code Coverage Report: This function allows you to run all available Apex Test Classes in the Salesforce org and generate a code coverage report. The code coverage report will be emailed to your registered email id with the CSV file attached. The CSV file will contain the failed test classes that require the user's attention to resolve. Select Do you want us to update the test classes? checkbox to avoid classes from getting overwritten after deployment.

  1. Attached is the sample email that will be notified to the user whenever the code coverage is run.

    • Code Coverage with a success rate of more than 75%

    • Code Coverage with a failure count of more than 20

    • Code Coverage with failure count of less than 20 (detailed error report will be included in the email body)

Salesforce Org - Mappings

Mapping your Salesforce org with your version control system or ALM configured in ARM. This helps create a control during a commit, merge, or deployment action performed on your Salesforce org or version control branch.

Suppose you want to connect your Salesforce Org with Version Control as a GIT.

  1. Click on the Mapping button for Version Control as GIT.

  2. Select the respective version control Repository and the Branch for your GIT.

  3. Click Test Connection to authenticate your connection.

  1. Remember to click on Save Mappings to save the details, or else you need to repeat the above steps.

In another scenario, let us assume you also like to configure JIRA (ALM tool) with your Salesforce org.

Important Note: To proceed ahead with the below steps, make sure the JIRA is successfully integrated with ARM (LEARN MORE)

  1. Click on the Mapping button beside JIRA.

  2. Select the Jira label and the Project from the drop-down list.

  3. Click on Save Mappings to save the details, and you're done.

Salesforce Org - Skip Members

In this section, you can add certain metadata members from your Salesforce org that will be skipped whenever any deployment happens to the org.

Suppose you want to skip Analytics Cloud Integration User, Analytics Cloud Security User, and Authenticated Website metadata members for the Profile metadata type. In such a case, select the Type as Profile under and click the Fetch Members button.

Select the metadata members from the list. These members will be skipped each time the deployment is performed on the above Salesforce org. Click OK.

Similarly, you can add different metadata members for various metadata types. Additionally, if you remember certain members you like to add manually, you can enter the Enter members manually field and click Add.

The Salesforce Org- Skip Members section shows a summary of the selected metadata members. Click on Save Members to save the steps configured.

Salesforce Org - Default Apex Test Class Configuration

This section is about configuring the default Apex Class for your Salesforce Org. This topic is covered in a separate article. Refer to the article HERE.

Salesforce Org - User Permissions

The list of users allowed to work with your Salesforce Org is available in this section. The administrator may assign permission to its users on various modules of ARM that are feasible with the Salesforce Org.

How do I update or change the username in all of the Salesforce Orgs specified in AutoRABIT?

To update the username on all registered orgs, re-authenticate the orgs in Admin > SF Org Management page.

How does AutoRABIT handle Salesforce Org Mapping?

  1. It was highlighted that users can edit the Salesforce Org mapping in their AutoRABIT profile and change the mapped username. This could potentially allow someone to associate a deployment with another user, raising a security concern around accountability if a deployment introduces issues.

2. How AutoRABIT Handles Salesforce Org Mapping

  • Integration (Non-Human) User: The best practice is that all deployments are executed using the integration (system) user that registered the Salesforce org with AutoRABIT. This username is what will appear in Salesforce deployment audit logs.

  • Triggered By User: AutoRABIT additionally records the actual user in AutoRABIT who initiated the deployment. This “Triggered By” information is available in AutoRABIT audit logs and reports, providing visibility into who performed the action, regardless of the Salesforce username mapping.

  • Org Mapping in Profiles: Changes to Salesforce Org mappings in a user’s profile only impact retrieval during EZ-Commit (e.g., fetching metadata by a specific developer or “all users”). For deployments, the integration user always takes precedence.

3. Expected Behavior

  • Deployment Logs in Salesforce: Will always show the integration user that registered the org.

  • Audit Logs in AutoRABIT: Will show both the integration user (deployed by) and the specific AutoRABIT user (triggered by).

  • Org Mapping Flexibility: Developers can adjust mappings to fetch metadata changes made by specific users or by all users, but this does not alter deployment accountability.

4. Steps in Case of Incident If an incident occurs and you need to review who executed a deployment:

  1. Check AutoRABIT Reports Module:

    1. Navigate to Reports.

    2. Download deployment reports (e.g., last 7 days).

    3. Review the columns “Deployment User” (integration user) and “Triggered By” (AutoRABIT user).

  2. Cross-Reference with Salesforce Audit Logs:

    1. In Salesforce, the deployment record will list the integration user.

    2. Use AutoRABIT’s “Triggered By” information to identify the specific individual who performed the deployment.

  3. Document Findings:

    1. Keep both sets of logs (Salesforce and AutoRABIT) for any postmortem or compliance reporting.

This ensures clarity on responsibility and traceability during audits, while maintaining security controls.

PreviousSalesforce OrgNextSalesforce Authentication using OAuth

Last updated

Was this helpful?