Salesforce Permission Sets and Flow UAT: What to Test Before Go-Live

Salesforce security and automation are not separate concerns. The access a user has determines what data a Flow can read or update, which approvals they can submit, what related records they can see, and whether they can recover from an exception. A release can pass all its configuration checks and still fail when a real sales rep, manager, or service agent performs the process.

The answer is role-led UAT: run critical scenarios with the profiles, permission sets, record ownership, sharing rules, and data conditions that exist in the production operating model.

Test access as a matrix of business actions

Do not test permission sets as a static spreadsheet alone. Translate the security design into actions: who can create, view, edit, approve, transfer, export, delete, or report on each record and field in the journeys that matter.

• —Sales reps, managers, operations users, service agents, finance users, administrators, external users, and delegated approvers.
• —Object, field, record, related-record, report, dashboard, list-view, file, action, mobile, and API access.
• —Records owned by the user, their team, another business unit, a queue, a territory, or an inactive owner.
• —Sensitive data that must remain hidden in screens, reports, exports, related lists, and integrations.
• —Boundary conditions such as a user who gains a temporary permission set, works across territories, or acts for another user.

Run Flow and approval scenarios with realistic records

A Flow that works with a newly created record may behave differently when it processes a migrated record, an owner change, an effective date, a currency, a related case, or a value updated by an integration. UAT should use the combinations that change the business outcome.

• —Create, update, convert, reassign, approve, reject, close, reopen, and delete or restore records where the business process permits it.
• —Test Flow entry criteria, decisions, scheduled paths, subflows, notifications, related-record updates, and integrations.
• —Confirm validation messages are clear to the affected user and do not leave half-completed business activity behind.
• —Exercise Flow fault paths and approval exceptions, then run the documented recovery procedure as the team who will own it.
• —Check interactions with existing automation, including Apex triggers, legacy Process Builder rules, managed packages, and integration updates.

Validate reporting and auditability

Security and automation defects can remain invisible until someone runs a report, investigates an approval, or tries to understand why a field changed. Test whether the organisation can see, explain, and evidence the outcome after the process has completed.

• —Verify reports and dashboards show the correct records and fields for each user role.
• —Confirm field history, approval history, error notifications, and integration status give the accountable team enough information to investigate.
• —Test that restricted data cannot be exposed through exports, report subscriptions, dashboards, or connected applications.
• —Reconcile automated outcomes with the business expectation and document any accepted exceptions before go-live.

Set release criteria around safe operation

A permission or Flow release is ready when the right people can complete the right actions, the wrong people cannot access or change restricted data, automation produces explainable outcomes, and failures can be detected and recovered safely. A successful deployment alone is not evidence of any of those conditions.

“The real test of Salesforce security and automation is not whether it works for an administrator. It is whether it works safely for everyone else.”