Preview the Approval Path (without submitting)
14 min
consider the following scenarios reps want to know who will approve a deal before they commit & submit it for approval deal desk wants to sanity check the routing on a freshly edited quote before handing it back admins want to validate additional items & route reps through a custom submission flow to extract more deal details all three scenarios share a goal see the approval path without initiating it on the preview page recent package versions decouple path preview from submission, so opening show approval path on a record page does not create an approval request and leaves the record untouched the supported pattern is preview on the record page using the built in show approval path button ( submitbutton lightning component) submit from wherever fits the workflow — the default submit button on the same component, or a custom button, quick action, screen flow, or lwc that calls the submit for approval invocable action decoupling preview from submit gives you full flexibility for the submit affordance without giving up the preview ui that the product maintains for you business scenarios covered scenario who uses it approach rep checks which approvers will see their quote before clicking submit sales rep show approval path button on the record page deal desk reviews the path on a quote mid revision deal desk coordinator show approval path on the record page (no submitrecordforapproval required) custom submit ux — preview on the record page; submit on a quote page button or screen flow elsewhere admin / custom flow author hide the default submit button via hidesubmitforapprovalbtn , then place submit elsewhere via the submit for approval invocable step 1 preview on the record page no configuration required beyond adding the approvals pro components to the record's lightning page confirm components are on the page open a record that falls under an approval process (e g , a quote) click the ⚙ icon → edit page confirm the submitbutton and approvalhistory components are on the layout add approval component to record page docid\ bwvkcrf7ysnsu7dvyjd8c save if anything was missing click show approval path on a record whose status qualifies it for submission, the approvals pro component renders a show approval path button clicking it opens a visual map of paths and steps — including which approvers will be asked, which steps will be skipped (and why), and the dependency ordering the button is visible even to users without submitrecordforapproval — so deal desk and ops can preview without having permission to submit no appro approval request c is created the record is untouched note preview evaluates the current record state if the record changes (e g , discount is edited), re open the preview to get fresh data step 2 hide the default submit button (optional) if you want the record page component to show only the preview affordance — and place submit on a custom button or screen flow elsewhere — toggle the package's hidesubmitforapprovalbtn setting what the setting does hides the submit button rendered by the default submitbutton component on every record page, org wide does not hide show approval path — preview continues to render does not revoke any user's submitrecordforapproval custom permission users who had submit access can still submit through any other ui surface that calls the submit for approval invocable how to toggle it navigate to setup → custom settings → approvals pro settings → manage find the row whose name is hidesubmitforapprovalbtn (the package seeds this row on install with value = false ) edit the row → set value to true → save refresh any record page using the approvals pro component — the submit button is gone; show approval path remains to re enable, set value back to false the setting is org wide there is no per profile, per record type, or per object override — toggling it affects all approvals pro record page components see also permissions → custom settings that gate behaviors step 3 place submit anywhere using the invocable action with the default submit button hidden, you can put a submit affordance wherever fits the workflow the supported entry point is the invocable action appro invocablesubmitforapproval — same engine the default button calls common placements a quick action of type flow on the quote page layout a list button that runs a screen flow over selected records a custom lwc on the opportunity record page or on a community page a screen flow that takes the rep through review screens before invoking submit on a final step for the full input/output reference, see invocable actions → submit for approval example submit on a quick action build a screen flow that takes record id as an input variable add an action step calling submit for approval record id {!recordid} (the input variable) approval process name leave blank to let approvals pro pick the highest priority eligible process — or pin a specific process by name add a final screen showing the action's success / error message outputs so the rep gets immediate feedback activate the flow on the target object (e g , quote), create a quick action of type flow , point it at this flow, and add it to the page layout's mobile/lightning actions example submit from custom apex (lwc backend) if you're building a fully custom ui (e g , a quote builder with its own submit affordance), call the global method directly public with sharing class quotesubmitcontroller { @auraenabled public static void submit(id quoteid) { appro approvalutilscontroller apexapprovalsubmit( new map\<string, object>{ 'recordid' => quoteid } ); } } see global methods → submit for approval for the full signature and error handling pattern permissions reminder whoever clicks your custom submit affordance still needs the submitrecordforapproval custom permission, just as they would for the default button hiding the default button does not change the permission model — it only hides one ui surface design guidance don't build a custom preview that hides configured approvers transparency is the point of preview — if reps learn they can't see who will approve, trust in the system erodes use the built in show approval path rather than building your own preview ui re preview on material change preview reflects the current record state after any edit that could affect routing (discount, amount, product mix), re open preview before submitting don't activate a new approval process version while in flight records are recalled smart approvals decisions don't carry across versions see best practices → smart approvals troubleshooting symptom likely cause fix show approval path button missing older package version, or the user lacks read on appro approval path c verify package version ( setup → installed packages ) and upgrade if older; grant approver or submitter permission set preview shows no paths on a record that should match entry criteria reference a field that's null on this record populate the field; or adjust the criteria submit button disappeared from every record page after a config change hidesubmitforapprovalbtn is set to true expected when this setting is enabled either set the value back to false (setup → custom settings → approvals pro settings → manage), or place submit elsewhere via the invocable action (see step 3) custom submit flow throws "insufficient privileges" or returns success = false with a permissions error running user lacks the submitrecordforapproval custom permission assign the approvals pro submitter permission set (or any custom permission set that includes submitrecordforapproval ) to the running user for record triggered flows, ensure the automated process user has it submit button still showing after setting hidesubmitforapprovalbtn = true browser/lightning cache hard refresh the record page (cmd/ctrl+shift+r) if still visible after refresh, confirm the setting row's name is exactly hidesubmitforapprovalbtn (case sensitive) and value is true related invocable actions → submit for approval — the action you call from custom submit uis global methods → submit for approval — apex entry point for fully custom implementations permissions → custom settings — where hidesubmitforapprovalbtn lives, plus other org wide toggles best practices → preview vs submit — design rules and rationale recall & resubmit — after submission, how to unwind if preview was misread