# Salesforce Org Management Page

{% hint style="info" %}
**Important Note:** This article is for the **Org Administrator** in particular. The actions discussed in the article will not be available to general users.  
{% endhint %}

### Overview <a href="#overview" id="overview"></a>

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

<figure><img src="/files/e0SIfPNL6WVpCB1LSjvr" alt=""><figcaption></figcaption></figure>

### Salesforce Org - Details <a href="#salesforce-org-details" id="salesforce-org-details"></a>

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

<figure><img src="/files/OjE7freeObypnWaUM7vD" alt=""><figcaption></figcaption></figure>

The fields displayed in this section are described in the table below:&#x20;

| 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**

<figure><img src="/files/9Q3DjZqHSV57vDisM4zL" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="/files/lXxUw6FKD7Y8DqxOr4eO" alt=""><figcaption></figcaption></figure>

4. 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%

   <figure><img src="/files/nnJnQRvqLtxFDfS1Fib0" alt="" width="375"><figcaption></figcaption></figure>

   * Code Coverage with a failure count of more than 20

   <figure><img src="/files/RBbVcICrqbTf6ahPFrLb" alt="" width="341"><figcaption></figcaption></figure>

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

   <figure><img src="/files/daOboMDxGrWCU7jrslya" alt="" width="301"><figcaption></figcaption></figure>

### Salesforce Org - Mappings <a href="#salesforce-org-mappings" id="salesforce-org-mappings"></a>

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.

<figure><img src="/files/Kk4QWMbcF3A4MYvReNEI" alt=""><figcaption></figcaption></figure>

Suppose you want to connect your Salesforce Org with Version Control as a **`GIT`**.&#x20;

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.

<figure><img src="/files/QE7Zj59m9etEbWWrvoJU" alt=""><figcaption></figcaption></figure>

4. 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.&#x20;

{% hint style="info" %}
**Important Note:** To proceed ahead with the below steps, make sure the JIRA is successfully integrated with ARM ([LEARN MORE](/product-guides/arm/integration-and-plugins/jira.md))
{% endhint %}

1. Click on the **`Mapping`** button beside JIRA.&#x20;
2. Select the **`Jira`** label and the **`Project`** from the drop-down list.&#x20;
3. Click on **`Save Mappings`** to save the details, and you're done.

<figure><img src="/files/z4KmC4BwTjX3Bd6jUYbN" alt=""><figcaption></figcaption></figure>

### Salesforce Org - Skip Members <a href="#salesforce-org-skip-members" id="salesforce-org-skip-members"></a>

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

<figure><img src="/files/5qzxwyvkDzujyXfmidBE" alt=""><figcaption></figcaption></figure>

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`**.

<figure><img src="/files/KdcwU0XHVodwUWmCMlG2" alt="" width="563"><figcaption></figcaption></figure>

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.

<figure><img src="/files/2ynk1jTdEJAzngOsQvkc" alt=""><figcaption></figcaption></figure>

### Salesforce Org - Default Apex Test Class Configuration <a href="#salesforce-org-default-apex-test-class-configuration" id="salesforce-org-default-apex-test-class-configuration"></a>

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](/product-guides/arm/troubleshoot/how-tos/default-apex-class-configuration.md).

<figure><img src="/files/rw0AiFXFu4e6EkSU0IPA" alt=""><figcaption></figcaption></figure>

### Salesforce Org - User Permissions <a href="#salesforce-org-user-permissions" id="salesforce-org-user-permissions"></a>

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.

<figure><img src="/files/xe9mGDZ3kAU2qXdWYep5" alt=""><figcaption></figcaption></figure>

### How do I update or change the username in all of the Salesforce Orgs specified in AutoRABIT? <a href="#how-would-i-go-about-updating-or-changing-the-username-in-all-of-the-salesforce-orgs-specified-in-au" id="how-would-i-go-about-updating-or-changing-the-username-in-all-of-the-salesforce-orgs-specified-in-au"></a>

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.&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://knowledgebase.autorabit.com/product-guides/arm/registration/salesforce-org/salesforce-org-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.