Permissions

permissions approvals pro ships three permission sets (admin, approver, submitter) and six custom permissions assigning the right combination to the right users is what turns the package from "installed" into "usable" this page lists what each permission grants, who typically needs it, and how to extend the defaults permission sets permission set who needs it what it grants approvalspro admin user approval process owners, salesforce admins full read/write on all approvals pro objects can create, edit, activate, and version approval processes, paths, steps, approvers, matrices, variables, conditions, and email templates approvalspro approver user anyone who approves records (managers, deal desk, finance, etc ) can see the home page pending approvals component, approve/reject/reassign assigned approvals, and manage their own delegations approvalspro submitter user anyone who submits records for approval (typically sales reps) can submit records via the submit component on a record page, view approval progress, and recall their own submissions note a user submitting and approving records (e g , a sales manager who submits their team's quotes and also approves peer submissions) needs both the submitter and approver permission sets custom permissions custom permissions sit inside permission sets and toggle specific behaviors the table below shows which custom permissions are pre assigned to each stock permission set ( x = included) custom permission admin approver submitter what it does approveallapprovalsatonceforoneapprovalrequest adds an "approve all" button to the approval screen — approves all pending approvals for all users on the current approval request in one click approveanypendingapproval x adds a button to approve any pending approval assigned to any user — useful for admins unblocking stuck workflows recallanyapprovalrequest x lets the user recall any approval request, not just their own showhomepagecomponent x drives visibility of the your pending record list component on the home tab used as a visibility filter, not a functional gate submitrecordforapproval x x enables the submit button on the record page's approval component viewprocessreferencesaslinks x renders references to processes, steps, approvers as clickable links in the approvals pro ui submitters and approvers should not have this — the links would 404 for them when to grant additional custom permissions recallanyapprovalrequest — grant to deal desk coordinators, ops teams, and qa teammates who need to pull back submissions they didn't originate see recall & resubmit approveallapprovalsatonceforoneapprovalrequest — grant to executives or approval aggregator roles who need to clear an entire request in one action (e g , a cfo resolving end of quarter backlog) how to grant a custom permission custom permissions can't be assigned directly to users you must put them inside a permission set setup → permission sets → new name it descriptively (e g , approvalsprorecallany ) open the permission set → custom permissions → edit move the custom permission from available to enabled save assign the permission set to users via manage assignments custom settings that gate behaviors some behaviors are controlled by org wide custom settings rather than per user permissions find them at setup → custom settings → approvals pro settings → manage setting default purpose allowrecallofapprovedrecord false when true , users with recallanyapprovalrequest can recall records that are already fully approved (not just pending ones) required to use smart approvals with a "change after approval" flow hidesubmitforapprovalbtn false when true , hides the default submit button on every record page using the approvals pro component, while leaving show approval path in place use this when you want submit to live on a custom button, quick action, or screen flow that calls the submit for approval invocable full walkthrough preview the approval path visibility considerations beyond permissions permissions alone don't guarantee an admin sees all approval processes in the org approval processes, paths, and steps are standard records — their visibility is governed by salesforce sharing (owd + sharing rules + roles), not just fls by default admin permission set grants full object access, but row level visibility still follows owd if an admin created an approval process, other admins may not see it unless owd is public or a sharing rule covers them common fix set the organization wide default for appro approval process c , appro approval path c , and appro approval step c to public read/write for admin facing teams if that's too open, create a sharing rule based on the role of the admin team required salesforce platform permissions beyond the approvals pro permission sets, users need a few standard salesforce permissions for the app to work apex record locking must be enabled at the org level ( setup → process automation settings ) required for the lock record after submit feature email deliverability must allow access to at least "system email only" ( setup → deliverability ) approvers need read on the object being approved (e g , quote, opportunity) without it, they can't open the record from the approval email related installation — where these permission sets are assigned initially setting up approvers — approver level email preferences recall & resubmit — recallanyapprovalrequest in context permission reference — deep reference table of every permission + object level access