# Best practices for managing user permissions in a multi-cloud environment Permission sets for the extra access, a named integration user, and no View All grant to make a demo pass. Profiles remain. **Published:** 2026-01-01 **Canonical:** https://synconai.com/user-permissions-multi-cloud-salesforce **Author:** SynconAI Architecture Team ## In short Use permission sets for the access a person needs, and a named integration user for anything that logs in as a system. Marketing Cloud users are not Sales Cloud profiles. Profiles are still there; permission sets are the cleaner model. Do not grant an agent or an integration View All access so a demo looks finished. ## Sources - **Agentforce: What is an AI agent?** (retrieved 2026-10-10) https://www.salesforce.com/agentforce/ > These agents generate responses that are consistent with your company’s brand voice and guidelines using trusted business data, including Salesforce CRM data, external data from Data 360, and more. - **About Salesforce Data 360** (retrieved 2025-10-14) https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5 > As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged. ## What to take away - Profiles remain. Salesforce cancelled the plan to retire them in June 2026. Permission sets are still the cleaner model for access you add. - One named integration user per integration, with a permission set limited to the objects that job reads and writes. - A Sales Cloud profile does not make a Marketing Cloud Engagement user. Next, Engagement, and Account Engagement are different user models. - Do not grant View All or Modify All to an agent or an integration so a demo can see everything. ## The guide 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](/insights/enterprise-salesforce-integration-best-practices). 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](/enterprise-ai-strategy-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. ::: warn View All and Modify All are not pilot settings. If you would not give that set to a contractor starting on Monday, do not give it to an agent or an integration so a workshop can finish. Put the grant back before anyone calls the demo a success. ::: 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. ## Questions ### Are Salesforce profiles being retired? No. Salesforce cancelled that plan in June 2026, and profiles remain. Do not run a programme that tells people profiles are going away. Permission sets are still the cleaner model for the extra access a person needs, especially when that access is a slice of a second cloud. The profile matches the job they were hired for, and the set is the extra that comes off when the extra ends. Cloning a profile to hold a temporary grant is how the grant becomes permanent. ### How should an integration log in? As a named integration user, one per integration, with a permission set limited to the objects that job reads and writes. Do not use a shared administrator, and do not grant View All or Modify All to make a demo look complete. One user per job is how you can tell which pipe read a field it should not have read. Name an owner for that user. When the project ends, the user still needs an owner, or it is a password nobody will freeze. ### Does a Sales Cloud profile cover Marketing Cloud? No. Marketing Cloud Engagement has its own users, roles, and business units, and Account Engagement has its own model. Marketing Cloud Next is closer to core Salesforce users and is a different product, so map each one. A marketer who only has a Sales Cloud profile will not be able to send from Engagement. An integration user copied from an administrator will be able to see too much, including business units the job does not serve. ### What can an agent user see? What that user is allowed to see. Salesforce describes agents as answering from trusted business data, including CRM data and Data 360, so grant the permission set the job needs. View All is not a shortcut to trusted data. If the reply can mention another account, the set is too wide, whatever the prompt says. Match the set to the source list and remove the difference before the pilot. A wide grant that made the demo pass is the grant you will still be running on Monday. ### How should we test permissions? As the integration user and as the agent user, not as a system administrator. Write down what each one can open, including fields, not only objects. Remove anything the use case does not need. An empty answer on a field the user should not see is a pass. Do not open sharing to make a row appear. Data Cloud was renamed Data 360 on 14 October 2025, and access to it is a separate grant, given only when the job needs those records. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Salesforce consultancy (https://synconai.com/salesforce-consultancy).