People, Integrations and Agents

Module 7 of 7 in the chapter Profiles, Permission Sets and Permission Set Groups, chapter 3 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: A person, an integration and an agent can all reach your data. What decides what each one can do once it’s in?

There are three ways into your org today. A person logs in on the screens. An integration comes in through an API. And now an agent comes in, working for someone or on its own.

How each one proves who it is, that’s different for each, and it’s the front door’s job. Chapter 2 covers the people, and the Integration Architect and Identity and Access courses go deep on the APIs and the agents. This course draws its line at the granting: once it’s in, what may it do? And here’s the thing. The answer is built the same way for all three. They all have a user license, a profile and permission sets.

Every way in is a user

Salesforce doesn’t let anything in without a user record. An integration logs in as a user. An agent works as a user. So every way in has the same three things this chapter has been about: a user license, one profile and the permission sets on top.

That’s good news for an architect. It means everything in modules 1 to 6 applies to integrations and agents too: a light profile for the door, small permission sets by task, groups by persona, access that ends, and policies that assign it. You don’t need a second security model for the machines.

What changes is the details. Let’s take them one at a time.

A person

You know this one. A user license, a profile kept light, and permission sets doing the work. The person gets exactly what their job needs, and the sharing model decides which records they open. Nothing new here, and that’s the point: it’s the pattern the other two follow.

An integration

The first rule is from the front door chapter: one integration, one identity. Salesforce says it plainly: “we recommend creating and configuring one Salesforce user for every integration.” A user for each calling system restricts each one “to a unique subset of data and functionality” (Give Integration Users API Only Access (opens in a new tab), Salesforce Help, checked 2026-11-01).

Then the grant, the same three pieces:

• The license. The Salesforce Integration user license, which module 6 covered: API only, never for a person.
• The profile. It comes with Minimum Access - API Only Integrations, which “enables and also restricts assigned users to operate via API. You can’t turn off the API-only access granted through this profile” (same page). That’s the light profile for the door, built for a machine.
• The permission sets. “Configure and assign permission sets or permission set groups to grant permissions to integration users so they can perform the API operations.” If the license doesn’t unlock enough, the Salesforce API Integration permission set license adds more (same page).

And one more grant you set: which app the integration may use. An external client app, or a connected app, can be set so that “only users with the associated profile or permission set can access the app.” Turn on Admin approved users are pre-authorized, then “manage access using profiles and permission sets” (Preauthorize User App Access Through External Client App Policies (opens in a new tab), Salesforce Help, checked 2026-11-01). Same tool again: a permission set.

Watch one permission on that page. Users with Use Any API Client can use any external client app, even one set to admin-approved users. Salesforce’s own warning: “As the name implies, you’re giving up your control over authorization” (same page). Treat it like View All Data.

As itself, or as the person

Here’s a design question I put in a scenario at Architect Dreamin’. An outside system pushes data into Salesforce. Should it log in as an integration user, or as the person it’s acting for? In my scenario, it had to “use specific operative credentials, not an integration user. After all, we want to keep track of who knows what!”

That’s a granting decision. If the integration comes in as its own user, it gets the integration user’s grants, and every record it touches is touched by “the integration.” If it comes in as the person, it gets that person’s grants and that person’s sharing, and the trail shows who. Neither is always right. But decide it on purpose, because it decides what the integration can see.

An agent

Agents come in two ways, and Salesforce’s own words make the link to integrations.

A service agent works as its own user. “Service agents operate as an agent user—a Salesforce integration user with all the permissions that the agent needs to do its job.” And “Creating a new agent user in the guided setup creates an agent user record with minimal access so that your agent is secure by default. Grant the agent the additional access that it needs” (Create an Agent from an Agentforce Service Agent Template (opens in a new tab), Salesforce Help, checked 2026-11-01).

Read that again: an agent user is an integration user. Everything in the last section applies. Minimal access, then permission sets for exactly what the agent’s job needs.

An employee agent works for the person using it, so there’s a second grant: who may use it. “Control user access to specific Agentforce Employee agents with permission sets or profiles,” through the agent’s Agent Access page or the Enabled Agent Access setting on a permission set or profile. On an Experience Cloud site, the agent “runs in the context of the logged-in site user,” and since sites often share one profile, Salesforce says to enable the agent on a permission set and assign it only to the users who should have it (Manage Employee Agent Access (opens in a new tab), Salesforce Help, checked 2026-11-01).

So for every agent, ask two questions. Who does it run as? And who may use it? Both answers are grants, and both are permission sets.

What the grant opens

Module 1’s grid lists everything a permission set can hold. For the three ways in, it falls into three groups:

• The offices: object permissions and field-level security, apps and tabs, record types, Apex classes and Visualforce pages, flows, custom permissions and the user permissions.
• The file cabinets: not on the permission set at all. Which records a user opens comes from its role and the sharing model, the 25 ways in chapter 5. An integration user and an agent user need a place in that model too, or they see only what they own and what’s public.
• Its tools: which connected apps and external client apps it may use, which external credential principals it may call out with, and which employee agents it may use.

Click to enlarge

Where this chapter ends

Everything in this chapter is structural security: can you see this object, this field, this tab, or not, whether you’re a person, an integration or an agent. If the answer is yes and the user still can’t see the record, the problem isn’t here. It’s in the file cabinets. Chapter 4 finishes the structural side with fields and the screen, and then the course turns to sharing records, where integration users and agent users need a place too.

What an architect decides here

• For each integration, its own user, with the Integration license, the API-only profile and permission sets for exactly its job.
• Whether each integration comes in as itself or as the person it acts for, and why.
• Which apps each user may use, with external client apps and connected apps set to admin-approved users, and who, if anyone, holds Use Any API Client.
• For each agent, who it runs as, with minimal access first, and who may use it.
• That integration users and agent users have a place in the sharing model, decided on purpose.

Beyond the exam: what AI changes. Every new agent is a new user to review. As agents multiply, the risk isn’t one agent with too much access; it’s dozens of agent users nobody looks at again. Review them like people: the same View Summary, the same three users in testing, the same question: why does it need this?

Explore

• Give Integration Users API Only Access (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Preauthorize User App Access Through External Client App Policies (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Create an Agent from an Agentforce Service Agent Template (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Manage Employee Agent Access (opens in a new tab), Salesforce Help (checked 2026-11-01)