Manage User's Account Settings
Last updated
Last updated
Important Note: This article is for the Org Administrator in particular. The actions discussed in this article will not be available to general users.
You can create, edit, and view user account details as an Org administrator. Admins can view their account details too.
Hover your mouse over the Admin tile and select My Account.
The My Account page appears. You’ll then be presented with a screen divided into different sections, as depicted below:
The Account Contact Details section contains your account's primary information and your subscription period with ARM.
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.
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 credentials checkbox 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 > Users section. Uncheck the Enforce SSO boxes after selecting the users from the list. Save the SSO Configuration by clicking Save.
Note: When the Disable login with AutoRABIT credentials option is selected, the Enforce SSO checkboxes are automatically checked for all the users.
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.
Browsers Supported:
Google Chrome 12+
Internet Explorer 7+
Firefox 3+
Developers must select the appropriate baseline branch to compare against. If they don't, a new branch will be created, which causes problems.
Admins can configure the default baseline branches for CodeScan and SonarQube SCA plugins in the My Account section. This resolves the confusion developers previously faced when selecting baseline branches for SCA and. It also helps Admins control the default baseline branches.
Configure the baseline branches
Select CodeScan or SonarQube.
Select Project from the dropdown list.
Click on the Select Default Branch field to display the available branches within the selected project, then click on the branch name from the list. You can choose multiple branches for each project. These branches are available for a developer to choose from during EZ-Commit.
Other options:
Click Save after selecting, adding, or deleting the required projects and corresponding branches.
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.
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
Select the 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.
Select the Auto reject commit process if the criteria are not met checkbox to auto-reject the commit if the set criteria are not met.
Auto approve on commit validation success: If all the criteria selected under Enable criteria based Review Process are successfully validated, selecting this checkbox will automatically approve the commit.
Important Note: The user can set the commit validation criteria under the Validation Criteria- Static Code Analysis section on the My Account page.
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.
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.
Select the Enable criteria based Review Process checkbox to enable the merge setting.
Merge Criteria
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 Levels drop-down box. The minimum approval level can be 1.
Auto approve on merge validation success: If all the criteria selected under Enable criteria based Review Process are 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 Settings section and tries to merge the files to a branch.
ARM supports all the metadata types based on the Salesforce API Version. ARM now supports the Salesforce API 62.0 version, which means it can support any Salesforce standard or custom objects that require Salesforce API version 62 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.
Packaging and Deployment Settings: Several options can be configured in this section:
Manageable States: In Salesforce, the ManageableState attribute indicates the status of a component within a package, reflecting its lifecycle stage and editability. The possible states are:
Beta: The component is in a managed package version marked as beta, suitable for testing but not for production use.
Released: The component is in a managed package version officially released for production use.
Deleted: The component has been deleted from the package.
Deprecated: The component is marked as deprecated, indicating it's outdated or should no longer be used.
Unmanaged: The component isn't part of a managed package, allowing full editing and deletion.
Installed: The component is part of a managed package installed in a subscriber's org, and it can't be edited or deleted by the subscriber.
InstalledEditable: The component is part of an installed managed package but can be edited by the subscriber.
DeprecatedEditable: The component is deprecated but remains editable.
b. 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.
c. 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.
d. Include/Exclude Metadata Types: Be sure to exclude them to avoid retrieving unwanted metadata types during the deployment or merge.
Important Note:
Enabling the Configuration for running delta on RecordType Picklist values checkbox may lead to more time for the build. If you deselect it, your build cycles will be shorter.
Rollback Settings
Ensure you exclude them to avoid retrieving unwanted metadata types during deployment or commits rollback.
Profile/PermissionSets Settings
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 New button.
Select the Salesforce Org.
Click either Get Profiles or Get PermissionSets.
Get Profiles will fetch all the profiles available in selected Salesforce Orgs.
Get PermissionSets will list all permission sets available in Salesforce Orgs.
Based on the above selection, choose either the Profile or Permission from 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.