Custom Permissions

Custom Permissions

Global Variables

- Out of the box (oob) Salesforce settings allow us to control the visibility of features such as
processes and apps
- But we can use Custom Permissions to manage access to functionality within these features,
allowing more granular customizations
- To create a Custom Permission, we navigate to the Custom Permissions page in Setup

Giving Custom Permission to Users

- Once we’ve created a permission, we can add it to a profile by clicking the Custom Permissions
link on the profile detail page when we’re using the Enhanced Profile User Interface
- If we’re using the regular profile user interface, we can hover the Enabled Custom Permissions
link at the top of the profile detail page

Using Custom Permissions

- We can refer to our permissions within formulas in validation rules, formula fields, flows, and
process builder by using the $Permission global variable, the API name of our permission, and
dot notation
o E.g. $Permission.Large_Discount
- Alternatively, we could check a user’s custom permissions using Apex with the
FeatureManagement.checkPermission() method
o This method takes a single argument - a string holding the API name of our permission
o Returns a Boolean value indicating if the running user has the permission

Custom Metadata Types

Custom Metadata Types (CMTs)

- Allow us to create, package, deploy, and even upgrade our own custom metadata
- Like custom objects, CMTs can have fields
o But these fields and the values they contain are metadata - not data (i.e. record data)
o So the instances (i.e. records) of a CMT are also metadata
o Therefore, we can migrate both CMTs and custom metadata records with any tool that
can deploy metadata (like the Salesforce Extensions for Visual Studio Code and the
Salesforce CLI)
 - CMTs are primarily used to hold configuration information for apps
- “configuration information” includes master data
o E.g. a postal company that has multiple Salesforce orgs can use CMT records to easily
migrate information about the prices for shipping different classes of mail (like
overnight or next-day air) between their orgs without having to manually create records
holding this information in each org

Creating CMTs

- To create a CMT, we navigate to the Custom Metadata Types page in Setup

Sidebar: Visibility Settings

- Determine access to our type and possibly its records

Visibility API Value Radio Button

Public Public All Apex code and APIs can use
the type, and it’s visible in
Setup.
Protected (Local) Protected Only Apex code in the same
namespace can see the type.
The name of the type and the
record are visible if they’re
referenced in a formula.
Protected (Managed) PackageProtected Only Apex code in the same
managed package can see the
type. The name of the type and
the record are visible if they’re
referenced in a formula.

- If we’re creating a managed package and we want subscribers/customers to be able to

o Change the CMT (i.e. create records of it), we should choose the Public setting
o Use the CMT, but not change, we should use the Protected (Managed) setting
- If we want to customers to be able to create records of the CMT, but not change existing
records, we….
o When we create a CMT, it gets some standard fields
o One of these standard fields, IsProtected can be edited by toggling the Protected
Component checkbox when creating/editing a record
o When we protect individual records, we can include a CMT in a managed package with
the Public visibility setting on the type
o So our CMT records will be protected, but customers can still make their own
 - We don’t really have to worry about customers changing the type itself, because there are very
few/heavily restricted CMT attributes that customers can change in a managed package
- We can modify records that have been released as part of a managed package by updating the
package or using Apex

Creating, Updating, and Deleting CMT Records

Metadata Namespace

- We can use Apex to create CMT records by adding one or more instances of
Metadata.CustomMetadata (a system-defined class that represents a CMT record) to a
Metadata.DeployContainer
o We’ll then pass this object and a callback function to
Metadata.Operations.enqueueDeployment()
o We use this method to retrieve, update, or insert CMT records because traditional DML
can’t do so
- Apex can’t delete CMT records
- We can create, update, and delete records declaratively from the Custom Metadata Types page
- If we want to read records in Apex, we can also use SOQL that queries the corresponding CMT
o There is no governor on the number of queries executed against CMTs in a single
transaction, as long we’re not querying Text Area (Long) fields
o But CMT SOQL queries are still subject to the 50,000 record retrieval transaction limit
- CMTs have API names in the format TypeDeveloperName__mdt

Using CMT Records

- We can reference CMT types and records declaratively in formulas included in flows, formula
fields, processes, and validation rules by using the $CustomMetadata global variable, followed
by the dot notation specifying the API name of the type
o If we’re referring to a particular field on a CMT record, we’ll append the API name of the
record and the field through dot notation to this syntax
 E.g.
$CustomMetadata.TypeDeveloperName__mdt.RecordDeveloperName.FieldAPI
Name

CMT Fields
- We can create custom fields on CMTs using the Checkbox, Date, Date/Time, Email, Number,
Percent, Phone, Picklist, Text, Text Area, and URL field data types
- We can also create custom relationships for CMTs, these can be
o Relationships to another CMT
o Relationships to an EntityDefinition (i.e. a standard/custom object)
 o Relationships to a FieldDefinition (i.e. a standard/custom field on a standard/custom
object)
- CMTs also have page layouts and (optionally) validation rules, although CMTs can’t be
declaratively displayed in the Salesforce UI

Custom Metadata Type Uses

- As we said earlier, we can use CMTs to hold configuration data
- We’ll also use them when
o Deploying a common secret (e.g. authentication information)
o We want to conditionally or skip triggers
o Mapping different objects or fields together metadata that will persist across
deployments