Salesforce continues to provide more and more features with direct access from the component level without developing in Apex. One of the more recent features made available directly to Lightning Web Components are Custom Permissions.
What Are Custom Permission?
Salesforce Custom Permissions are designed to provide a flexible, customizable approach to control access within an application. They allow administrators to define access rights at a granular level and developers to reference them in code. Here’s a brief breakdown of what Salesforce Custom Permissions are and what they should be used for:
Use Cases
Feature Access Control: They can be utilized to control who has access to certain features within an application. For example, access to specific buttons, sections, or any custom functionality can be controlled using custom permissions.
Custom Code Authorization: Developers can reference Custom Permissions in Apex code or Visualforce pages to control who can execute specific code paths. This enables a level of dynamic access control within custom code.
Component Visibility: Custom permissions can be used to control the visibility of certain components on a page based on the user’s permissions.
Advantages
Flexibility: They offer a high degree of flexibility in controlling access to custom functionality.
Maintainability: By encapsulating access control logic in a centralized manner, they can make the application easier to maintain and modify over time.
Creation and Assignment
Creating Custom Permissions involves defining a name and a label for the permission. Once created, these permissions can be assigned to users via Permission Sets or Profiles.
The assignment of Custom Permissions is quite flexible. They can be granted to users, groups, permission sets, or even entire profiles, allowing for a broad or narrow scope of access control based on the need.
Feature Implementation
Below is an direct example from Salesforce Documentation, referencing a Custom Permission from a Lightning Web Component, except with some more consistency.
hasPermission.js ----------------- import hasPermission from "@salesforce/customPermission/PermissionName"; import hasPermissionManaged from "@salesforce/customPermission/namespace__PermissionName";
hasPermission references a Custom Permission that is unmanaged, while hasPermissionManaged is how you would reference a Custom Permission with a namespace.
hasPermission.js
-----------------
export default class App extends LightingElement {
get isDisabled() {
return hasPermission;
}
}
hasPermission.html
-----------------
<template>
<setup-panel-group>
<setup-button disabled={isDisabled} onclick={openSetup}></setup-button>
</setup-panel-group>
</template>
As you can see, they’ve made using the value of a Custom Permission very easy, creating a GET’r to use for an inline visibility flag.
See the Creating and Assignment header for examples how to relate the permission to various entities for access.

