Manage User's Account Settings
Last updated
Was this helpful?
Last updated
Was this helpful?
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 63.0 version, which means it can support any Salesforce standard or custom objects that require Salesforce API version 63. 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.
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.
Vlocity integration with ARM allows you to retrieve and deploy Vlocity metadata in the same way as for the Salesforce metadata, and commit the changes either to the repository or to a Version control branch.
Vlocity Version Supported: v1.17.1
Integrate Vlocity as a plugin in ARM
In the Vlocity Configuration Settings section, select the Enable Vlocity checkbox.
Next, you must select the various parameters required to integrate Vlocity with ARM:
Compile On Build: When selected or set to true, the compileonbuild code is modified in the YAML file, and the same gets committed to your Version Control branch during the EZ-Commit process. When you're trying to deploy to a Salesforce org using the above-configured branch, the compilation will take place before the deployment begins. However, ARM recommends that you keep this checkbox unselected. This is because the Vlocity tool throws compilation errors when you're trying to deploy the data that doesn't have dependent components when Compile On Build is checked.
Auto Update Settings: This option ensures you have the latest Data Pack settings before each export and deployment. This check is quick, and we recommend that you allow it.
Separate Matrix Versions: Add the ability to export matrix versions separately.
Local Compilation: To perform a local compilation of FlexCard and OmniScript metadata types, select this checkbox and enter the Access Key of Vlocity's private NPM repository to load the OmniStudio LWC compiler and deploy the compiled objects.
NoteIf you do not have the NPM repository Access Key, you can request one from your Vlocity customer representative at https://repo.vlocity.com/repository/vlocity-public/, by filing a support case with the subject Request for Access Key to Vlocity's Private NPM Repository.
MaxDepth: MaxDepth decides the level of dependencies that will be executed while fetching and committing vlocity components. By default, MaxDepth is set to -1.
When MaxDepth Values is set to -1 means, it will execute all-level dependencies of selected data pack record
When MaxDepth Values is set to 0 means, it will execute only selected data pack record and
When MaxDepth Values is set to 1 means, it will execute only first-level dependencies of the selected data pack record.
Data Pack Types: This gives you an option to choose your specific Vlocity components that will be committed to your destination org/branch.
Click Save.
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.
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 3 months.
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
Important Note: The clean-up of the historical data will run every Saturday. To access any historical data that has already been cleaned up, contact us at support@autorabit.com, and we will provide the data in a CSV file format. Deleted data cannot be restored to the application.
Click the icon to add a project.
Click theicon to remove a branch from a project.
Click theicon to delete the project completely.
