> For the complete documentation index, see [llms.txt](https://knowledgebase.autorabit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://knowledgebase.autorabit.com/product-guides/arm-1/getting-started/signing-up-with-arm/user-profile.md). # User Profiles Numerous configuration options are available to users when setting up their profile in ARM. The **`Profile`** section allows users to view and update their basic information, personal email settings, etc.
To access user preferences, click your user name in the upper right corner and select **`Profile`**.

### Personal Details The **`Personal Details`** section displays your full name, ARM user name, email address, phone number, etc. Your personal details will be populated, as the system administrator must enter this information when creating a new user account. In this section, you can update your name, phone number, address, etc., accordingly.\

{% hint style="info" %} **Important Note:** 1. **System Administrators** can change your **Email** and **Username**. 2. To avoid conflicts and get correct data while conducting any activity in ARM, ensure the **Time Zone** you set here matches the time zone you defined in Salesforce. {% endhint %} ### My Projects The **`My Projects`** section will list all the projects that you have created or have permission to view. Users with admin-level permissions will have access to all projects. ### My Roles The **`My Roles`** displays the list of roles assigned to the user. If you have admin roles and permission, you can perform all the tasks an administrator can perform and access all modules within ARM. ### About Skip Mappings If users maintain an individual version control branch for every release, they must map every branch to Salesforce Org and Version Control branches to keep synchronizing with Salesforce Org. To overcome this daily routine, ARM provides the option to skip the Org Mappings part and directly perform commits. ### My Salesforce Orgs {% hint style="info" %} NOTE: 1. If a sub-user does not have access to the **"**SF ORG MGMT**"** page and the Skip Mapping option is not enabled for their profile, they will be unable to view the mapped Salesforce Orgs in EZ Commit, even if they have permission to access those Orgs.
To resolve this issue, the admin must grant the sub-user access to the **"**SF ORG MGMT**"** page. This can be done by selecting the human icon in the screenshot below.

1. Then, the sub-users can view the mapped Salesforce Orgs in the EZ Commit screen once the user is added. {% endhint %} View the **`Salesforce Orgs`** assigned to you, or you have permission to view.\

### My Version Control Mappings View the Version Control Repositories here based on the Salesforce Orgs selected in the **My Salesforce Orgs** section. \ You can view the list of all repositories configured under each version control system (VC). Select a repository to display its branches. From there, map the required branches by choosing the appropriate **`Credential`** from the drop-down field. Click **`Test Connection`** to determine whether the connection has been authenticated or not.

### My ALM Mappings Under **`My ALM Mappings`** section, you can map your ALM using your credentials or **`Re-Authenticate`** Jira ALMs configured with OAuth access.\

For ALM type **`IBMRTC (IBM Rational Team Concert)`** and **`JIRA`**, we have added the filter to fetch specific work items according to the filter applied.

According to the filter set, only specific work items will get fetched. When the developers progress (via EZ-Commit or merge operation in ARM) on updating the ALM status, they are reflected on the corresponding work items. If the user wishes to discard the filter selected, uncheck the **`Apply My Filter`** option, and all work items will get fetched. ### My Default Page **`My Default Page`** is the first page that appears when you log in to ARM. You can customize ARM to open any page as the default page.

## Mapping Your Profile with Version Control and Salesforce Org 1. Go to the **Profile** section. 2. In **My Salesforce Orgs**: * Select the Salesforce Org. * Assign the Salesforce Org user. 3. In **My Version Control Mappings**: * Select the repository. * Assign the user. 4. Click **Save**. 5. Go to **Admin > SF Org Mgmt**: * Select your org. * Open **Salesforce Org – Mappings**. * Choose the mapping for the version control you set up. * Click **Save Mappings**. Screenshots for each section are attached above to guide you through these steps. If you maintain a separate Version Control branch for each release, you must map every branch to the Salesforce Org to keep them in sync. To simplify this, use the **Skip Mapping** option under **Profile > My Roles**. This allows you to bypass org mappings and commit directly when appropriate. ## Uploading Multiple Profile Files **413: Status Error**: Users may encounter a 413-status error in the browser console when trying to upload duplicate profile files that have been resolved after downloading from version control. This occurs when users try to download numerous files at one time. Download one profile file at a time to resolve the error. ## Setting Up an Integration User for ARM An integration user is a dedicated Salesforce user that ARM uses to connect to your Salesforce org. Commits, validations, deployments, and data operations that ARM runs against the org appear in the Salesforce audit trail as that user. ARM also records the ARM user who started the job. Salesforce deployment history shows the integration user. ARM audit logs show both the integration user and the ARM user who triggered the work. Use one integration user for ARM. Do not share that user with other tools. {% hint style="info" %} **Note**: An integration user is not the same as the Salesforce Integration user license. The first is the Salesforce user ARM signs in as. The second is a Salesforce license type. ARM requires a standard Salesforce license. {% endhint %} #### Recommended Setup Create one integration user in your production org. Use that same user to register production and every sandbox in ARM. When you refresh a sandbox from production, Salesforce copies production users into the sandbox. If the integration user exists in production, it is copied automatically. You do not need to create a new user or rebuild permissions after each refresh. Salesforce appends the sandbox name to the copied username. For example, becomes . The password from production is copied. After a refresh, update the username in ARM and validate the connection. If you create a separate user only inside each sandbox, the refresh replaces that user, and you have to set it up again. #### Why the System Administrator Profile ARM works through the Salesforce Metadata API. A release can include Apex, flows, fields, layouts, profiles, permission sets, roles, sharing rules, reports, dashboards, email templates, translations, custom permissions, and connected apps. Each of those metadata types has its own Salesforce permission. The System Administrator profile grants those permissions and continues to cover new metadata types that Salesforce adds in a seasonal release. If your security policy does not allow an administrator profile on a service account, use a custom profile and permission set as described below. Review that permission set after each Salesforce seasonal release. A missing permission usually shows up as one metadata type failing while the rest of the deployment succeeds. #### Alternative: a custom profile with a permission set Create a custom profile with minimal base permissions. Create a permission set with the access below and assign it to the integration user. **Access settings**

Setting	Value
Assigned apps	All apps
Apex class access	All classes, including system classes
Visualforce page access	All pages
Custom setting definitions	All custom settings
Custom metadata types	All custom metadata types

#### **System permissions** This list covers the full range of metadata a release can contain. Grant the ones that match what you deploy. If you never deploy org security settings, for example, you can leave out Manage IP Addresses, Manage Password Policies, Manage Login Access Policies, and Manage Session Permission Set Activations. The Needed for column tells you what each one is there to support.

Permission	Needed For
API Enabled	Every call ARM makes. Nothing works without it
Modify Metadata Through Metadata API Functions	Every retrieve, validation, and deployment. Required in all cases
View Setup and Configuration	Reading setup, and the Setup Audit Trail ARM uses for change detection
View All Data	Running Apex tests during validation and deployment
Author Apex	Apex classes and triggers
Customize Application	Objects, fields, picklists, and layouts
Manage Profiles and Permission Sets	Profile and permission set deployment, and Profile Manager
Manage Roles	Roles and the role hierarchy
View Roles and Role Hierarchy	Retrieving the role hierarchy
Manage Sharing	Sharing rules
Manage Custom Permissions	Custom permission deployment
Manage Custom Report Types	Custom report types
Create and Customize Reports	Reports
Create and Customize Dashboards	Dashboards
Create and Customize List Views	List views
Create Report Folders	Report folder creation during a deployment
Create Dashboard Folders	Dashboard folder creation
Create Folders for Lightning Email Templates	Lightning email template folders
Manage Reports in Public Folders	Shared reports
Manage Dashboards in Public Folders	Shared dashboards
Manage Public List Views	Shared list views
Manage Public Classic Email Templates	Classic email templates
Manage Public Lightning Email Templates	Lightning email templates
Edit HTML Templates	Classic email template content
Manage Public Documents	Shared documents
Manage Reporting Snapshots	Reporting snapshots
Manage Data Categories	Data categories for Knowledge articles
Manage Translation	Translations and object translations
Manage Connected Apps	Connected apps and External Client Apps
Manage Package Licenses	Reading managed package namespaces
Manage IP Addresses	Deploying org security settings
Manage Login Access Policies	Deploying login access settings
Manage Password Policies	Deploying org password policy settings
Manage Session Permission Set Activations	Session-based permission sets
Manage Synonyms	Knowledge article synonyms
Modify Data Classification	Field data classification and privacy settings
View All Custom Settings	Custom settings
View All Users	Metadata that records user ownership
Password Never Expires	Prevents the service account password from expiring

**Add these only if you use the feature**

Permission	Needed For
Bulk API Hard Delete	Dataloader hard delete operations. Leave it off unless you use hard delete
Object-level create, read, edit, and delete	The specific objects your Dataloader jobs touch. Grant per object
Dev Hub enabled on the org, with scratch org permissions	Salesforce DX scratch org creation

Salesforce adds metadata types in each seasonal release, and some arrive with a new permission. When a deployment fails on one metadata type and everything else succeeds, check the permission set first. #### Connecting the Org Register each org with OAuth or OAuth through an External Client App. Go to Admin > SF Org Mgmt. For the full registration steps, see[ ](https://knowledgebase.autorabit.com/product-guides/arm/registration/salesforce-org)[Registering Your Salesforce Org](https://knowledgebase.autorabit.com/product-guides/arm/registration/salesforce-org) and[ ](https://knowledgebase.autorabit.com/product-guides/arm/registration/salesforce-org/register-salesforce-org-using-oauth-via-external-client-app-eca)[Register Salesforce Org using OAuth via External Client App (ECA)](https://knowledgebase.autorabit.com/product-guides/arm/registration/salesforce-org/register-salesforce-org-using-oauth-via-external-client-app-eca). Both methods open the Salesforce login page so the integration user can approve access. The integration user must therefore be able to sign in to Salesforce. Leave API Only User off. **Do not build a new connection on username and password authentication.** *Salesforce is retiring the authentication methods that use a username, a password, and a security token.* #### Why the Salesforce Integration license cannot be used Salesforce provides a Salesforce Integration user license for system-to-system API access, and several customers ask whether ARM can use it. It cannot, and the reason is worth stating clearly so you do not spend time on it. The license requires the Minimum Access - API Only Integrations profile, shown in some orgs as Salesforce API Only System Integrations. On that profile, API Enabled and API Only User are both switched on and cannot be turned off. API Only User is the setting that stops a user from reaching the Salesforce login page. ARM registers orgs with OAuth or OAuth through an External Client App. Both open the Salesforce login page so the user can approve access. A user who cannot reach that page cannot complete a registration or a re-authorization. So the license and the registration methods are incompatible. Use a standard Salesforce license for your ARM integration user, with either the System Administrator profile or the custom profile and permission set described above. #### Settings that prevent avoidable outages * Set Password Never Expires on the integration user's profile or permission set. An expired service account password stops every commit, CI job, and deployment at once, and the error message does not always say the password expired. * Exempt the user from login IP ranges, or add the AutoRABIT IP ranges to the trusted list on the profile. If the org restricts login by IP and AutoRABIT addresses are not allowed, the connection is refused. Contact AutoRABIT Support for the current ranges for your region. * Do not use a person's Salesforce account. When they leave, change their password, or reset MFA, the pipeline stops. * Use one integration user for ARM only. Sharing an account across several tools makes the Salesforce audit trail harder to read and means one tool's password change can break another tool. #### After a sandbox refresh A refresh replaces the sandbox with a copy of production. The connection has to be re-established. 1. The integration user is copied from production, so there is nothing to create. 2. The username now includes the sandbox name, for example, . 3. Confirm the permission set is still assigned. 4. Re-authorize the org in Admin > SF Org Mgmt. using OAuth or OAuth through an External Client App. Sign in as the integration user when Salesforce prompts you. #### Common problems and what causes them

What You See	Usual Cause
The org will not register at all	API Enabled is missing, or the user cannot complete the Salesforce login page
Registration or re-authorization fails at the Salesforce login page	API Only User is enabled. Turn it off so the user can approve OAuth access
The user is on the Salesforce Integration license and cannot register	That license forces API Only User on. Move the user to a standard Salesforce license
Everything works, then all jobs fail at once with no obvious change	The password expired
Login is refused from ARM but works in a browser	Login IP ranges are blocking AutoRABIT addresses
Most of a deployment succeeds and one metadata type fails	A permission specific to that metadata type is missing from the permission set
Deployments fail after a Salesforce seasonal release	A new metadata type arrived with a new permission requirement
Everything breaks after a sandbox refresh	The username now carries the sandbox suffix and needs updating in ARM
The permission set will not assign to the user	The user is on a license that does not accept that permission

#### In short Create one integration user in production on a standard Salesforce license, give it the System Administrator profile, and connect every environment with it. This is the least work to set up, the least work to keep working, and it survives a sandbox refresh. If your security policy does not allow that, use the custom profile and permission set in this article, and review it after each Salesforce seasonal release. Register orgs with OAuth or OAuth through an External Client App. The integration user must be able to sign in to Salesforce to approve access, so leave API Only User off. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://knowledgebase.autorabit.com/product-guides/arm-1/getting-started/signing-up-with-arm/user-profile.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.