ChatGPT
Claude
Google AI
Copilot
Permissions across Salesforce clouds stay readable when two habits hold. Extra access is a permission set. Anything that logs in as a system is a named integration user. Profiles are still part of the user model. In June 2026 Salesforce cancelled the plan to retire them. Do not run a programme that tells people profiles are going away. Permission sets remain the cleaner place for the access you add on top: an object, a field, a system permission, a second cloud.
The failure is a demo that looked finished. The agent could not see the order, so someone granted View All on the user it runs as. The workshop applauded. On Monday the grant is still there. A customer asks about their own order. The reply mentions a balance from a different account, because the user can see every account and the model is trying to be helpful. Nothing in the prompt made that data trusted. The permission did. The incident report is short. The user could open everything.
A second failure sits beside it, and it is easy to miss because it looks like a training issue. A marketer is told their Sales Cloud profile is their Marketing Cloud login. They cannot send. The integration user, built from an administrator so the connector would "just work", can see every business unit. The person who needs the access does not have it. The system that should have had a narrow set has all of it. Both mistakes come from treating one cloud's user as if it were the others.
An agent that answers from CRM data and from Data 360 can see what its user can see. Data Cloud was renamed Data 360 on 14 October 2025. You may still see the old name in the product. Wide access makes a demo look finished. It also makes the incident report short, because the user could open everything. Salesforce describes these agents as generating responses from trusted business data. Trusted includes "this user is allowed to see it". View All does not make data trusted. It skips the review.
Permission sets, and the profile that stays
Give a person a profile that matches the job they were hired for. Add permission sets for the extras, and use a permission set group when the bundle should be assigned as one. When the extra access should end, you remove the set. You are not left comparing two cloned profiles to remember which checkbox was the temporary one. The clone is how a "temporary" View All becomes a second profile named "Service - agent pilot - DO NOT USE", which is then used, because it is the one that makes the demo work.
Profiles remain. The cancelled retirement is not a reason to invent a new home for access, and it is not a reason to keep cloning profiles either. The profile answers who the person is: seller, agent, admin. The permission set answers what this person may do beyond that, for a time, for a reason. Write the reason on the set's description. "Needed for the March pilot" is a reason. "Misc" is how the set survives the pilot. When the reason expires, the assignment expires with it. Put the date in the calendar of the person who administers permissions, not in a comment nobody reads.
A permission set group is for a bundle you intend to grant and revoke together. It is not a place to hide a wide set inside a reasonable name. Open the group and read the sets. If one of them contains View All or Modify All, the group is that grant, whatever the label says. The label will be what the access review quotes. The contents are what the agent can see.
The integration user
The integration user is a named user, one per integration, with its own permission set. The set includes the objects that integration reads and writes, and nothing gathered while you are here. No shared administrator password. No View All and no Modify All so a demo can see every record. If the integration cannot do its job without that grant, the design is wrong. Narrow the job or fix sharing. Keep the grant off.
One user per integration is how you know which pipe misbehaved. A shared user that files orders, reads invoices, and pushes consent will show up in the log as a single name, and you will not know which job read the field it should not have read. Split them. Name them after the job, not after the vendor. The person who owns that job owns the user. When the project ends, the user does not become orphaned. Who funds the pipe and who is called when it fails are the same programme questions as the rest of the estate, in integration at programme level. An integration user with no owner is a password waiting for an incident.
The same rule binds an agent user. The set matches the source list for that use case, and nothing beside it. The strategy that names the permission review, and the kill criterion if the user had to be widened, is in an enterprise AI strategy on Salesforce. This page is how that review is done. A strategy that says "security reviewed" and a user that can see every account are the same failure described twice. Sign the set against the list. If they differ, the list wins, or the use case is not ready.
Login history and the permission set assignment are the two things you keep. A user that has not logged in since the project closed is a candidate to freeze, not a candidate to ignore. Freezing is reversible. A shared administrator password is not a user, and it cannot be frozen without stopping the people who also depend on it. That is why the integration has its own name.
Marketing Cloud is a different user model
Marketing Cloud Engagement has its own users, roles, and business units. A Sales Cloud profile does not make someone an Engagement user. Account Engagement has its own user model as well. Marketing Cloud Next sits closer to core Salesforce users, and it is not those two products. Map each one on purpose. A sentence that says the CRM profile will cover marketing is how you discover, late, that the marketer cannot send and the integration can see too much.
Write the map in one table the admin can keep. This Salesforce user. This Engagement user, or this Marketing Cloud Next permission set. This business unit. This purpose. Review it when someone changes role. Remove the marketing access when they leave the marketing job, even if the Sales Cloud profile stays. The person who moves from marketing to sales should lose the send right the week they move. The profile can stay. The marketing user, or the Next set, comes off. Leaving both is how a seller can still launch a journey they no longer own.
Business units are a boundary, not a label. An integration user that can see every unit can export every audience, including the one a region is not allowed to mail. Scope the user to the unit the job serves. If the job truly crosses units, say so, name the owner who accepted that, and keep it as its own user with its own review. Do not inherit "all units" from the administrator who installed the package.
Account Engagement users are not Engagement users with a different logo. A person who can score a prospect there may have no right to send from Engagement, and the reverse. Write both lines. Marketing Cloud Next, because it sits closer to core users, is the one people will try to solve with a profile clone. Do not. A permission set for the Next job, assigned to the core user, revoked when the job ends, keeps the same habit as the rest of the CRM. It still is not an Engagement login. Connecting the core user to Next does not create the other two.
Data 360, tested as the real user
Data 360 access is its own grant. Put it on a permission set that matches the use case. The agent or the integration receives that set only if the job needs those records. Administrators do not get it by default so someone can see. An administrator who can open every unified profile will use that path during a demo, and the demo will pass for a reason the real user does not share. Take the admin out of the test.
Test with the user who will actually run. If the test passes only as a system administrator, you tested the wrong user. Open the records as the integration user and as the agent user. Write down what each one can see. That list is the permission review. Anything they can see and the use case does not need is a set you still have to remove. Include the fields, not only the objects. A user who can see the case and can also see a card number on a related record has failed the review even if the object list looked narrow.
An empty result is a pass when the field is supposed to be invisible. Opening sharing until a row appears is the breach. Record the empty result in the review notes so the next person does not "fix" it. The fix is the incident.
Run the test again when you add a source, a business unit, or a field to the source list. A new field on an object the user can already read arrives for free, and it may be the field you meant to exclude. The review is the diff, not a once-a-year ceremony. The person who signs the set signs the diff. The data owner signs the list. Two signatures, the same week, or the grant does not go on.
What the note contains
The permission review is a page, not a meeting that "covered security". One row per user that runs without a person sitting there: the integration users and the agent users. For each row, the permission set, the objects, the fields that matter, what was opened in the test, and what came back empty on purpose. The date. The two names. A row that says "admin, so we could see" is a row you delete by narrowing the user, not a row you file.
When someone asks for a wider grant later, they are asking to edit that page. The edit names the field, the reason, and the date the extra comes off. If they cannot name the field, they are asking for View All again, in a longer sentence. Decline it. The Monday after the demo is when that sentence usually arrives, dressed as a small exception. The exception is the incident, waiting.
