Manage User's Account Settings (My Account)
You can create, edit, and view user account details as an Org administrator. Admins can view their account details too.
View User Account
- Hover your mouse over the
Admintile and select
My Accountpage appears.
- You’ll then be presented with a screen divided into different sections, as depicted below:-
1. Account Contact Details (Read only)
The Account Contact Details section contains your account's primary information and your subscription period with ARM.
2. Subscription Type (Read only)
Subscription Types are set up to match your organization's requirements. View the current subscription type and list of modules granted by ARM based on your subscription. Click on
View Models to view the complete subscription model.
3. SSO Configuration
Single Sign-On (SSO) is an authentication process that allows a user to access multiple applications with only one set of credentials. ARM uses the secure and widely adopted industry-standard Security Assertion Markup Language 2.0 (SAML 2.0), which means our implementation of SSO integrates easily with any large identity provider that supports SAML 2.0.
SAML-based SSO enables two-way communication between an authentication server (the Identity Provider) and an application (the Service Provider). So, your account must be set up to declare who will be the authentication server and how the communication must work.
Using the information you gathered from your IdP (the Identity Provider), fill in the below details:
Entity ID: String that uniquely identifies your IdP (your IdP generally provides it).
Uploaded File Name: You must upload the XML file generated from IdP. (For more information, please refer to the Integration section on SSO.
Disable login with ARM credentials: When selected, passwords on ARM are no longer used once the SSO is activated. The system forces you and your sub-users to log in via SSO rather than entering their username and password on the login page. However, once disabled, all the authentication requests will go through the classic login interface.How to override single sign-on (SSO)?Sub-users registered to that organization cannot log in to the ARM application using the standard (username + password) approach if the
Disable login with AutoRABIT credentialscheckbox is selected. If the org admin wants to override the SSO configuration for an individual user or group of users, he can do so under the
Admin > Userssection. Uncheck the
Enforce SSOboxes after selecting the users from the list. Save the SSO configuration by clicking
Note: When the
Disable login with AutoRABIT credentialsoption is selected, the
Enforce SSOcheckboxes are automatically checked for all the users.
4. Mail Extensions
The admin can add different mail extensions based on the organization's requirements in this section.
This allows new users to sign up for the ARM account by giving their mail extensions.
This section lists various plugins that are configured in ARM. Based on the organization's requirements, admins can select the desired plugins to be used and register by giving the correct credentials.
In addition to this, the admin can select the desired browsers to execute the selenium test cases. Selenium cannot automate desktop applications; it can only be used in browsers.
- Google Chrome 12+
- Internet Explorer 7+
- Firefox 3+
6. Validation Criteria- Static Code Analysis
With the current release, users can set the global criteria to enforce
Static Code Analysis (SCA) tools across CI jobs and merge jobs. Based on the priority set, the build will be successful only if the criteria are met. The build will only succeed if the Apex Classes, Triggers, and Visualforce pages pass the priority set.
7. Commit Validation - Approval Settings
Here the admin can specify specific evaluation criteria for which the commit will get reviewed before being committed to the version control branch.
Auto reject commit after XX days
Auto rejects an approval for pre-validation commit after the days mentioned here.
Enable criteria-based Review Process
Enable criteria based Review Process checkbox to enable the commit criteria.
Next, choose the approval criteria based on your requirement:
Enable file comparison reports:When selected, this generates a code difference report upon completion of the commit operation.
Should pass validation criteria for Static Code Analysis: Select this option if you would like to run a static code analysis tool to identify potential software quality issues before the code moves to production.
- Select the SCA tool according to your requirements.
Auto reject commit process if the criteria are not metcheckbox to auto-reject the commit if the set criteria are not met.
- Select the SCA tool according to your requirements.
Auto approve on commit validation success:If all the criteria selected under
Enable criteria based Review Processare successfully validated, selecting this checkbox will automatically approve the commit.
Validation Criteria- Static Code Analysissection on the
Auto commit on Approval
Once the reviewer has approved the changes, or if you have opted to auto-approve upon successful validation, the commit process is automatically pushed to the destination branch.
8. Merge Settings
Here the administrator can specify specific evaluation criteria on which the merge will be reviewed before committing to the version control branch. The New Merge screen reflects the same option based on the criteria selected.
Enable criteria based Review Process checkbox to enable the merge setting.
Enable file comparison reports:When selected, this generates a code difference report on completion of the merge operation.
Should pass validation criteria for Static Code Analysis:Select this checkbox to run one or more SCA tools to identify potential software quality issues before the code moves to production.
Should pass mock Deployment:This allows the users to perform a validation deployment before committing the changes. If the deployment is successful, the commit is executed. This option only permits the merge operation to proceed if the deployment is successfully validated. Here, you need to specify the code coverage percentage, beyond which allows proceeding for validation deployment, or else the deployment fails.What is a Code Coverage Report?The code coverage report details the apex tests run, the classes covered, and the failed assertions. It also provides a percentage of the code covered by the test execution.
Disable Merge Self Approval:This option allows the Admin to prevent users who have committed to a merge request from approving it.
Auto commit on Approval:This option allows developers to work on their feature branches, and after review (approval), it gets automatically committed to the trunk. View the commit revision information when you click the Revisions link.
Enable Merge Approver:Enables the pprover to perform enforced code review by requiring specified people to approve a merge request before it can be unblocked for merging. Please set the number of necessary approvers before open merge requests can be merged under the
Approval Levelsdrop-down box. Note: Minimum Approval Level can be 1.
Auto approve on merge validation success:If all the criteria selected under
Enable criteria based Review Processare successfully validated, selecting this checkbox will automatically approve the merge. The merge will appear to have been approved by ARM. If the user has selected multiple approver levels, both levels will automatically be approved upon successful validation.
Notify All Criteria Overwrites To:The email address(es) specified here will receive an overwrite email notification every time the user tries to overwrite the evaluation criteria set in the
Merge Settingssection and tries to merge the files to a branch.
9. Salesforce Settings
ARM supports all the metadata types based on the
Salesforce API Version. ARM now supports the Salesforce API 57.0 version, which means it can support any Salesforce standard or custom objects that require Salesforce API version 57 or earlier. The newly supported Salesforce objects for each API version can be found here.
Select the API version to see the supported metadata types and avoid errors while accessing Salesforce orgs in Version Control, CI Jobs, Deployment, or SFDX modules.
Configuration for recordTypes picklistValues:This topic is covered separately. Click here to go directly to the mentioned topic.
Configuration for Translations:Options to choose the configuration for the LabelTranslations, i.e., either replace or append. When selecting the Replace option for the Configuration for LabelTranslations option for every EZ-commit operation, if the Label Translation has no custom label metadata type, it will override the LabelTranslations in Version Control, even if it has more than one custom label metadata type value. For the Append option, instead of overriding the custom label metadata types, it keeps adding to the existing one.
Configuration for running delta on RecordType Picklist values:On selection, this allows you to check delta on RecordType Picklist values during a Deployment.Important Note:Enabling the
Configuration for running delta on RecordType Picklist valuescheckbox may lead to more time for the build. If you deselect it, your build cycles will be shorter.
Packaging and Deployment Settings
Several options can be configured in this section:
Exclude Baseline Managed Package Changes:Upon selection, it considers only modified/changed metadata members and not base components of the managed packages.
Include Default Apex Tests For Run Tests Based On Changes:When selected, the default configured tests are added to the set, even if Test classes or Apex Class Apex Triggers are unavailable. Apex Test Level executes as RunSpecifiedTests. However, if the checkbox is unchecked, no default tests are added, and no Apex Test Level is set. Salesforce default behavior is expected in such cases.
Enable Delta on PermissionSets:Per the Salesforce behavior, for Salesforce API 40 or later, all PermissionSets are replaced with the latest changes. However, when the Enable Delta on PermissionSets checkbox is selected, the PermissionSets are retrieved from the source org and will append with the latest changes in the deployment package.
Include/Exclude Metadata Types: Be sure to exclude them to avoid retrieving unwanted metadata types during the deployment or merge.
Ensure you exclude them to avoid retrieving unwanted metadata types deployment or commits rollback.
This section pertains to granting or revoking permissions to the
Profiles/PermissionSets of any org. Based on the permission granted or revoked, the same is affected after committing the custom object in the Version Control.
What is a Profile?
Profiles define how users access objects and data and what they can do within the application. When you create users, you assign a profile to each one.
What are Permission Sets?
A permission set is a collection of settings and permissions that give users access to various tools and functions. Users can have only one profile, but they can have multiple permission sets. You can assign permission sets to different users, regardless of their profiles.
Create a Profile or Permission Set permissions
Create permission sets to grant access among logical groupings of users, regardless of their primary job function. For example, if you have an Inventory custom object in your org. Many users need
Read access to this object, and fewer users need
Edit access. You can create a permission set that grants
Read access and assign it to the appropriate users. You can then create another permission set that gives
Edit access to the Inventory object and assign it to the other group of users.
- Click the
- Select the
- Click either
- Get Profiles will fetch all the profiles available in selected Salesforce Orgs.
- Get PermisionSets will list all permission sets available in Salesforce Orgs.
- Based on the above selection, choose either the
Permissionfrom the list.
- Next, grant or revoke the permissions for the selected Profiles/Permission Sets.
Additional configuration for "Field Permissions" and "Object Permissions" settings
Field Permissions represent the field-level permission for users assigned to a profile.
|Editable||Indicates whether this field is editable (true) or not (false).|
|Readable||Indicates whether this field is readable (true) or not (false).|
Object Permissions represent a user's access to custom objects.
|allowCreate||Indicates whether the object referenced by the object field can be created by the users assigned to this profile (true) or not (false).|
|allowDelete||Indicates whether the object referenced by the object field can be deleted by the users assigned to this profile (true) or not (false).|
|allowEdit||Indicates whether the object referenced by the object field can be edited by the users assigned to this profile (true) or not (false).|
|allowRead||Indicates whether the object referenced by the object field can be seen by the users assigned to this profile (true) or not (false).|
|modifyAllRecords||Indicates whether the object referenced by the object field can be read, edited, or deleted by the users assigned to this profile (true) or not (false), regardless of the sharing settings for the object.|
|viewAllRecords||Indicates whether the object referenced by the object field can be read by the users assigned to this profile (true) or not (false), regardless of the sharing settings for the object.|
10. Session Settings
After logging in, a user establishes a session with the ARM platform. As an admin, you can control when an inactive user session expires. The default session timeout is 30 mins of inactivity. When the session timeout is reached, users are prompted with a dialog that allows them to log out or continue working.
11. Retention Policy
In this section, the admin can define the period for which data is retained by ARM in the history tables.
Clearing historical and irrelevant data from the database helps prevent the application from lagging, resulting in better performance in all modules. The default retention period is set as
12 months. Data older than 12 months will be automatically cleaned. Admins can later change it to
6 months or
This is applicable to the historical data on the following pages::
- Deployment history
- CI Job History
- Org Sync History
- Commits page
- EZ-Commits history
- Prevalidation commits history
- Reverted commits history
- Merges history
- Prevalidation merge history
- Merge Requests history
- External Pull Requests page
- Branching baseline page
- Change the Labels page
- Commit Labels
- Release Labels
- ALM Labels