SM Help Guide
Home / SM Help
SPECIALIZATION MANAGER USER GUIDE
Installation and Configuration of Specialization Manager from the AppExchange
TABLE OF CONTENTS
INTRODUCTION
Specialization Manager is a Salesforce-native center designed to streamline the management of all Salesforce security components. This document is a User Guide – a descriptive and comprehensive document designed to guide a Customer through the app’s features and capabilities, with a target to help customers reach the full potential of the Specialization Manager application. This is an advanced guide and it is assumed that a person reading it is familiar with basic Salesforce language and features.
BACKGROUND
Generally speaking, any Salesforce implementation has a finite number of security archetypes. A security archetype is a distinct type of user access configuration. The bottom line is the following: if two different users have identical read/edit access to objects/fields/records they belong to the same security archetype, otherwise they represent two separate ones. If an organization only has system administrators and salespeople – such an organization has two security archetypes. Once we add a compliance team that makes three. More archetypes – more complexity.
Specialization manager as an app is centered around Specialization – a concept that combines the majority of salesforce security systems under an umbrella of a single object. A single saved Specialization record represents a single security archetype used in this organization.
WHY SPECIALIZATION MANAGER?
Once salesforce implementation reaches a certain complexity, you can no longer simply create a new Profile per security archetype. Aside from it not being a Salesforce-recommended approach and exponentially increasing complexity over time, it is simply impossible for objects that require additional licenses. Therefore any Salesforce implementation past the bare minimum would use Permission Set/Group(s) and other advanced security concepts. There is no way in native Salesforce to save what types of users are supposed to use which types of Permission Set/Group(s). There is no good way to structurally organize your permissions stored outside Profiles.
Simply put: In core Salesforce, one can find the answer to the question “Does person Y have access to X?” but the interesting question “Is person Y supposed to have access to X?” can not be answered in Salesforce alone without Specialization Manager. The answer to this question normally requires saving security configurations in spreadsheets outside Salesforce and we are here to fix it.
Specialization Manager allows you to store various Salesforce security mechanisms as a single Specialization and apply them to users. This functionality enables the following improvements:
AUTOMATE ACCESS TASKS
Streamline and automate routine administrative tasks, saving significant time and resources in managing Salesforce security components.
SWIFT ISSUE RESOLUTION
Resolve internal access cases within minutes. No more employees blocked due to access constraints.
SHARED UNDERSTANDING
Eliminate ambiguity in understanding who is supposed to see what. Ensure every team member involved in the organization’s growth understands current access levels, fostering a unified vision across Product Managers,
Project Managers, and Developers.
PROACTIVE SECURITY
Specialization Manager’s organization scan swiftly identifies and highlights security problems within your Salesforce instance, ensuring continuous compliance.
ACCESS
The application usage requires the following permissions on the running user:
customizing applications and edit users. Customizing applications requires permission to edit custom metadata and editing users is a common functionality of the app. If a user is missing any of these permissions they will see a generic “Insufficient Privileges” Salesforce error instead of the app’s screens. We recommend installing (and using) the app for all System Administrators.
In case your organization uses a custom System Administrator profile to use the application it is required to manually provide them with permissions above and access to Specialization Manager apex classes (in case where the app was not installed for all users).
DATABASE
SPECIALIZATION SPECIALIZATION__MDT
Specialization is a custom metadata object used by the Specialization Manager. This object represents Specialization – a collection of salesforce settings that define the User’s access within the application.
Label
API Name
Format
Description
Name
Name
Text
Name of the Specialization. Used to connect Specialization to Users. It is recommended not to rename existing specializations.
Label
Label
Text
Same as name
Profile
Profile__c
Text(150)
This field stores a salesforce Profile using Profile name. If Profile is blank, the value is not enforced by this Specialization. Required field.
Role
Role__c
Text(150)
This field stores a salesforce Role using the Developer name. If this field is blank, User Role is not enforced by this Specialization.
Permission Sets
PermissionSetArea__c
Long TextArea (15000)
This field stores a list of Permission Sets that are part of this Specialization Advanced :
Permission Sets are stored as a comma separated list of developer names.
Permission Set Groups
PermissionSetGroupArea__c
Long TextArea (15000)
This field stores a list of Permission Set Groups that are part of this Specialization.Advanced :
Permission Set Groups are stored
as a comma separated list of
developer names.
Is Active
IsActive__c
Checkbox
This field controls if the specialization can be assigned or applied to new users. Inactive specializations can be stored for archiving purposes or as work in progress till their configuration is completed.Defaults to True.
Custom Field API Name 1… Custom Field API Name 5
CustomFieldAPILabel1__c … CustomFieldAPILabel5__c
Text(100)
This field stores the API label of a
field on the User object. Corresponding field would get assigned value from “Custom Field Value 1” field on this specialization. Detailed information in Note 1 after the table.
Custom Field Value 1 …Custom Field Value 5
CustomFieldValue1__c… CustomFieldValue5__c
TextArea(255)
Use this to store value that needs to be assigned to a User field stored in “Custom Field API Name 1” field on this specialization. Detailed information in Note 1 after the table.
Description
Description__c
Long Text Area(15000)
Use this to save any notes or relevant information.
Enforce Empty Role
EnforceNullRole__c
Checkbox
Enforce Empty Permission Set Groups
EnforceNullPermis sionSetGroups__c
Checkbox
Enforce Empty Permission Set
EnforceNullPermis sionSet__c
Checkbox
NOTE 1
Custom Field API Name and Custom Field Value fields are used to add an existing custom field from an User object to become a part of Specialization. For configurations of these fields real API (backend) values have to be used, these fields do not support Labels as Labels are not unique.
Example: Organization has a User Lookup field on User object named “Operating Manager”, API name “Manager__c”. That field value is used in custom security calculations. In this case Specialization “Sales Representative” can be configured to
have “Custom Field API Name 1” = “Manager__c” and Custom Field Value 1 = “005D500000*****” where “005D500000*****” is User ID of the Operating Manager for “Sales Representative” team. With this configuration field “Operating Manager” with predefined value will become part of Specialization “Sales Representative”.
Important: In addition to general access to the application, User that is configuring Specialization must have edit access to the field on the User object that is being added. (in the example above – edit access to “Operating Manager” field on User object).
Supported Field Types: STRING, TEXTAREA, DOUBLE, PICKLIST, EMAIL, BOOLEAN, REFERENCE.
Important: Specialization Manager code does not bypass any validation or custom code already created in Customer organization. The custom field is an advanced feature and can be configured in such a way that the User update will fail. It is in the Customer’s best interest to make sure the saved Value is a valid type for the corresponding Field.
NOTE 2
Enforce Empty Role EnforceNullRole__c. This field is created for the purpose of differentiating two separate behaviors for Specialization Manager when the Role field is empty. These scenarios are following :
Scenario one: Customer’s intent is not to have Role as a part of Specialization. For example there is a Compliance team, they all have the same object access but they have different Roles because they oversee records in different geographic locations. In this case Role is set up manually outside of the Specialization Manager’s reach. For this scenario Enforce Empty Role is False. Applying such Specialization will not alter any preexisting value in the Role field. Organization Status check will not flag any value in the Role field of a User with such specialization as an error.
Scenario two : Customer’s intent is to have an empty Role. For example there is a Sales team and any member of that team should not have any kind of role configured. For this scenario Enforce Empty Role is True. Applying such Specialization will set the Role field to empty. Organization Status check will flag any non-blank value in the Role field of a User with such specialization as an error.
Enforce Empty Permission Sets EnforceNullPermissionSets__c Has the same behavior as above but for Permission sets. If Enforce Empty Permission Sets is False. Applying such Specialization will not alter any pre-existing Permission Set configurations. Organization Status check will not flag any kind of assigned Permission Sets as an error.
Enforce Empty Permission Set Groups EnforceNullPermissionSetGroups__c Has the same behavior as above but for Permission set groups. If Enforce Empty Permission Set Groups is False. Applying such Specialization will not alter any pre-existing Permission Set Groups configurations. Organization Status check will not flag any kind of assigned Permission Set Groups as an error.
USER OBJECT
Label
API Name
Format
Description
Specialization
Specialization__c
Text(200)
Represents Name of Specialization that is assigned to this User.
Specialization uses the name of the Specialization object as a connect reference point. Changing this field manually in edit User UI or via data loader would assign Specialization but would not result in Specialization being applied. That means the value of the User field Specialization__c will change but it won’t bring all the consequences like Profile/Role change, Permission Set assignments and so on. Only the Specialization Manager application UI has functionality to apply Specializations.
FUNCTIONALITY AND UI BREAKDOWN
All Specialization Management interactions happen in the Specialization Manager app. Specialization Manager app consists of 3 main tabs:
Specializations, User Management and Organization Status
SPECIALIZATIONS TAB
This tab is used to view, create, edit and assign Specializations
1- List view of all specializations. Filter supports search by Name/Label. Selected specialization is shown on the right side in area 2
2 – Detailed view of Specialization selected in list view in area 1. For specific field details please see the Database section of this guide.
3 – Action items for this Specialization. “Add Users” and “Apply” actions are disabled for non-active specializations.
- “Edit” opens the edit menu for this Specialization.
- “Add Users” redirects to the “User Assignment” tab with this specialization selected.
- “Apply” – forcefully reapplies this Specialization to all users that have it configured. Use this button to propagate new Specialization changes to the entire user base or for initial configuration via dataloader route (see User Adoption guide).
4 – Action items on list view – ability to create a new Specialization and clone
Specialization from another Specialization or from a User (New from…).
CREATE FROM OVERLAY
Create from allows cloning existing Specialization or an existing User into a new
Specialization. Specialization cloning replicates all configurable fields except Name/Label as every name or Label must be unique. User into Specialization cloning carries following configurations from User object: Role, Profile, Permission Sets, Permission Set Groups.
CREATE/EDIT/CLONE NEW SPECIALIZATION OVERLAY
For specific field details please see the Database section of this guide.
Only difference between New and Edit options is that Name can not be changed post Specialization creation.
Important: Since Specialization_mtd is a custom metadata object the Save procedure can not be completed normally and actually starts an asynchronous deployment process to deploy desired change to the target Salesforce instance. Another deployment or another simultaneous metadata change can interfere with Specialization save. After saving it is recommended refreshing the table to see results.
Note: Rational Cloud recommends to treat Specialization changes the same way you treat security changes in Profiles/Permission Sets – for medium to large orgs that would include tests in sandbox and deploy in Production once desired outcome is achieved. Remember Specialization is an umbrella object that represents a security archetype in your organization.
USER MANAGEMENT TAB
User Management is a second tab in the Specialization Manager application. This tab purpose is to assign specializations to the User base. Specializations assigned via this tab have their effect applied to the underlying User(s).
ORGANIZATION STATUS TAB
This tab is designed for management/compliance applications. Since Specializations save the entire expected User access configuration, by comparing Specialization settings to real User status we can identify users who have wrong Profile/Role/extra Permission Set assigned or are missing some
1 – Main area with Scan results. Shows breakdown per type of possible misconfiguration. Number of Users with misconfiguration don’t have to sum up to anything, a User who has incorrect Profile and Role would show up in both sections.
2 – Filter for main area 1. The filter is necessary for very large organizations, User Scan is limited to 10.000 users and combination of Filter and Order By is used to scan different areas of user base for organizations that exceed this amount.
EXAMPLE EXPANDED SECTION WITH PROFILE MISMATCH
The Expand feature has a limitation in the amount of users that can be shown at once. Download full list button doesn’t have that limitation and would return up to 10.000 User list as a .csv file.
ADDITIONAL DETAILS
WHY SPECIALIZATION MANAGER?
Once salesforce implementation reaches certain complexity, you can no longer simply create a new Profile per security archetype. Aside from it not being a Salesforce recommended approach and exponentially increasing complexity overtime, it is simply impossible for objects that require additional licenses. Therefore any Salesforce implementation past bare minimum would use Permission Set/Group(s) and other advanced security concepts. There is no way in native Salesforce to save what types ofusers are supposed to use which types of Permission Set/Group(s). There is no good way to structurally organize your permissions stored outside Profiles. Simply put : In core Salesforce one can find the answer to the question “Does person Y have access to X?” but the interesting question “Is person Y supposed to have access to X?” can not be answered in Salesforce alone without Specialization Manager. Answer to this question normally requires saving security configurations in spreadsheets outside Salesforce and we are here to fix it.
WHY SPECIALIZATION_ _MDT IS A CUSTOM METADATA AND NOT A REGULAR OBJECT OR CUSTOM SETTINGS?
We view Specializations as a part of your Salesforce configuration i.e. part of Metadata in your Salesforce instance, not part of data in it. In RationalCloud we think that refreshed sandboxes have to come with Specializations configured. We want a Specialization change to be a deployment process, not a record change – similar to a change in a Permission Set or other records we oversee. We want to give you the ability to deploy new Permission Sets together with updated Specializations and treat it as a release.
WHY BEHIND THE SCENES SPECIALIZATION_ _MDT SAVES PROFILE, ROLE, PERMISSION SET AND SO ON WITH DEVELOPER NAMES/LABELS AND NOT WITH SALESFORCE IDS?
This allows to keep more complex development and deployment processes intact. Once a developer configures a new Permission Set in a Sandbox and assigns it to be a part of one or more Specializations this entire change can be moved to production in a single deployment.
