A couple of weeks ago I was excited to write about the free integration users that Salesforce has granted to all organizations. As of that writing the licenses were still rolling out, so nobody had really had a chance to use them. Now that they’re available, there’s been a great deal of discussion/confusion about how to actually make them work. If you wade through the Trailblazer Community thread in that link, you can figure it out for yourself. But I thought it would probably be helpful if I wrote up clear instructions.
As it turns out, the free integration user licenses are free like a beer. But it’s like they’re a beer bought by your high-maintenance friend. Perhaps after you’ve helped him assemble Ikea furniture. Or helped him move. Or both. That is to say, it’s a bit of work to use these free licenses.
The steps you have to take are:
Create a user with the Salesforce Integration user license and the only profile that you will have an option for once you have selected that license: Salesforce API Only System Integrations. (Or modify an existing user to have this license and profile.)
In that user record, under Permission Set License Assignments, assign the Salesforce API Integration PSL. (I do not understand what a permission set license is or does. But without it you can’t assign a permission set in step 3 that grants the access you are going to need. I know you have to do this because of the Help article about the integration user licenses.)
Create a permission set (or permission set group) that grants access to the right objects and fields.
Assign that permission set to the user.
That sounds pretty simple in black and white right there. But Step 3 is going to feel like assembling the worst Ikea project ever.
Permsets are the Future
What makes using the new Salesforce Integration user a challenge really comes down to the fact that integration user licenses come from a future in which permissions no longer reside on profiles. So you have to assign a permission set in Step 3 or else the integration user can’t access any objects or fields. But you and I don’t yet live in Salesforce orgs where all permissions are granted via permission sets ("permsets"), so we don’t have a permission set ready.
In January 2023, Salesforce announced, via a blog post from Cheryl Feldman, that permissions on profiles will “end of life” at the Spring ‘26 release. We’ve known for a couple of years already that permission sets and permission set groups were the future of user management but Cheryl’s announcement put a deadline on the transition to focus our minds.
The simple summary of that transition is that in the future every user will have a profile that grants basic login rights and a small handful of deep system privileges but all permissions related to object and field visibility will be layered onto users via permission sets. (Probably, users will get one or more permission set groups, which allow you to group permsets and then grant them all to a user at once. But it’s easier to discuss just in terms of permsets.) This is a better way to be able to manage user access by the principle of least privilege, in which you only give people access to those parts of Salesforce they need to do their job.
Most organizations today, particularly the smaller nonprofits that I’ve worked with, have a couple of profiles that grant wide permissions. Even if they are given different profiles, program users and development users can see all the same objects and fields. The difference in the profiles may be that their page layouts or app defaults are different, but fundamental permissions are the same. Honestly, I suspect that most organizations probably use just a single profile (other than sysadmin). And for most of the rest, that have two or three profiles, a side-by-side comparison would show very little difference between them.
It’s just rarely worth the effort to make the profiles very different in a small org, as there’s most people will need to see both program and development data. Since users can have only a single profile, what would you make someone that needs to see both program and development data? (Please don’t say, “We just make them a sysadmin.”) You would need either a “program and development profile” or you would have to manage both the profiles and some permsets for granting the other set of permissions.
There just isn’t enough time in the day to put a ton of effort into ensuring that we have profiles with minor differences in object and field permissions. And as of right now, Salesforce is still mostly built to accommodate using profiles as the main differentiator. Permsets have existed for a while, but they’ve generally been secondary to profiles that have the bulk of permissions. (For example, when you install from the AppExchange the installer offers to "install for all profiles," with no options relating to permsets.) Even if you want to be forward thinking about using permsets, it’s still a little harder to manage.
That was my long way of saying that in my experience most orgs manage user permissions through profiles primarily, if not exclusively. Even those of us that are interested in moving toward the future probably have only taken baby steps along that path.
Licenses from The Future
So, back to the free Integration User licenses. It’s not really just the licenses that appeared in orgs last month, there is also a profile to go with them, called Salesforce API Only System Integrations, which is the only profile you can assign to the integration user.
And this is a profile from The Future: It can’t have object permissions. If you clone that profile and try to add, say, Read and Edit on Accounts, you’ll find that object settings for Account simply aren’t there. The new Integration User license can only take the Salesforce API Only System Integrations profile and that profile can’t be given access to any of the objects and fields you need it to see. That’s because, like I said, it’s from the future.
(Just be glad it’s not here to assassinate us to prevent a future rebellion.)
Fortunately, the user profile from the future can be granted permission sets. So all you need is a permission set that grants access to the objects and fields your integration user is going to need. Depending on what that integration user does, that might be a short or a very long list.
If I’m setting up the integration user for a form tool, for example, I expect that it’s eventually going to need access to most, if not all, of the same objects that power users need. Just think about it, I could make a form for:
Donations, which, depending on the complexity of the need, could require access to Account, Contact, Opportunity, Payment, Campaign, Campaign Member, GAU, GAU Allocation, Product, Pricebook, Task, User (to assign the task) and probably several more.
Program Registration, which would require access to our custom objects for Program, Enrollment, etc…
Surveys, which would require access to Contact, Survey, and possibly several more.
So you can see that for some integration users you’re going to need a permset that grants a lot of access, as much as (or possibly more than) some users need. Even if you are super-conscious of security and only add iteratively to the form tool integration user’s permissions as you build each form, the final result is going to be a pretty extensive permset. And it's probably not one you already have.
Prepare for the Future Today
So we have the reality that at least one of your integration user’s permissions are going to be quite wide. Let me add the other consideration that a whole lot of orgs today have integrations logging in as sysadmins (either an integration user on a sysadmin profile or—worse!—sharing the login of a person who is a sysadmin). I would, therefore, argue that anything we do to grant permissions to the integration user granularly is going to be a security upgrade, even if “granularly” still starts from a large pile of permissions.
So as you set up your permission set to make the integration user work, think about it as preparing your org for the user management regime of Spring 2026 and beyond. That means you’re going to make a permset for the integration user that serves as the foundation of your permset for human users.
Permission to Build in Production [Temporarily] Granted
I think I’m pretty consistent in reminding people to only build in sandboxes, never directly in production. (Though I also am realistic and think there are certain changes that it’s perfectly reasonable to make directly in production. I should probably write a future post on that...) Unfortunately, you simply can’t realistically work in sandboxes for this purpose because of the way profiles and permission sets deploy.
When a profile or permset is deployed via a change set (or other deployment management tools), the only parts of it that actually deploy are those that relate to the other metadata that is deploying with them. That’s pretty interesting, if you think about it, because it means that Salesforce doesn’t just deploy a file for the profile or permset, but actually compares what it’s uploading to what is already there and only edits inserts, leaving the rest of the file alone.
This interesting functionality supports deployments coming from people working in different sandboxes. If it didn’t work that way, for example, then Jodi would deploy her new custom object, Cars, and a modification to the Program Manager profile granting access to Cars and its fields. An hour later, when Aaron deploys the flow he’s been working on (in a different sandbox) that works with fields only on Contact and Account, his Program Manager profile is coming from an environment that doesn’t have Cars. Aaron’s deployment would overwrite what Jodi deployed, removing access to Cars for the Program Manager profile. So it’s usually quite handy that Salesforce deployments of permissions relate only to the metadata that comes along.
But if you are trying to build a permission set that grants access to all objects, all fields, all tabs, and all record types, you would have to build up a change set that also includes all of those things. First, good luck ensuring that you get every relevant object and field into your change set without missing something. Second, the changes you send with all that metadata may overwrite or revert things that have changed in production and are out of sync with the sandbox you were working in. (I know you should have procedures for deployments to avoid that kind of overwrite, but it’s a lot harder to ensure it doesn’t happen when we’re talking about every object and field, which includes all descriptions, all help text, etc.)
Copado Essentials, formerly ClickDeploy, my deployment tool of choice, has a “profile only deployment” option. As I understand it, that means that you add all the other metadata to your deployment to indicate the parts of the profile to send. But when it actually is sent, it’s only the profile that moves over. Interesting. But there is no such thing as a “permission set only” deployment. I hear that Gearset has the ability to do a permission set only deployment, but I couldn’t figure out how. I don’t think Salesforce’s native Change Sets allow for either of these options.
Besides: Have I mentioned my skepticism that you would manage to add all the relevant related metadata to your change set without missing something? Copado Essentials makes it pretty easy to Select All and I’m still paranoid that something would be missed. Adding all the metadata into a change set via the native Salesforce change set tool is too painful to even contemplate.
So...you’re going to build your new permset in production.
Building the Standard User Permset
Now I have bad news for you: It’s going to take hundreds of clicks to build out your permission set. Maybe more than a thousand.
If you work in just one org, at least you can take comfort in only clicking hundreds of times once over. A solo consultant like me gets to do it for each of my client orgs. Ouch.
Worse yet, I determined that you have to do this work directly in production the hard way. By “the hard way,” I mean that I did the hundreds of clicks in a client sandbox, with the intent of testing that the integration user had all the permissions it needed before I moved to production. Then I found that I couldn’t deploy the permset and had to hand rebuild it in their production org! Double ouch.
Hopefully sometime in the next few years Salesforce will put out tooling that makes this easier. (I know that Cheryl Feldman and her team are already working on some of it.) But unless you want to wait for better tools before you use the integration licenses you’re going to have to go through this pain now. (And having done so, you might not even need the better tools later. Womp womp. 😞)
As noted above, I think at least one of your integration users is going to need similar permissions to a standard user (or possibly a little bit more), so I’m going to write these instructions on the assumption that you are building out a single base permset that actually has quite a lot of object and field permissions. If you have only integrations that have limited permission needs, you should build them very limited permsets (again: the principle of least privilege). But if you have at least one integration user (like your form tool) that needs a lot, this is the time to build a wide baseline permset. It’s easier to clone that permset and edit down to make less-privileged versions later.
Here’s what you need to do:
1. Make a new permission set. (Setup>Users>Permission Sets>New)
You can call it something like “MyOrg Standard.” I always recommend a Description. (Help Future You remember how this permset is used.) Do not associate it with a license type—leave that picklist blank.
2. In the permission set, go to Object Settings.
(I’m assuming you’re using the Enhanced Profile User Interface. If you are not, go immediately to Setup>Users>User Management Settings and move the slider to Enabled. I don’t know how anyone works with the classic profile/permset editor!)
Here you will have a list of all the objects in your org.
(You'll also see a bunch of things such as “App Analytics Query Requests” that are listed as objects but maybe aren’t quite? I don’t understand it. Just ignore those.)
3. Open one of the objects, perhaps in a new tab. Let's take Accounts as our example, since it's at or near the top.
This profile is going to need at least Read access for every object the integration user might touch, including Accounts. Given that the integration probably inserts and/or updates data, I think you probably want to grant Create, Read, and Edit (“CRE”) for each of those objects. (Most integrations and most standard users probably don’t need to delete, so we’re not going to grant that permission.)
You are also going to need to grant edit for most fields on each of those objects. And for those fields that aren’t editable (like formula fields) you need the integration user to have read access for that field. This is where the enormous amount of clicking comes in, as there is no Select All button. Sigh.
[And to make things worse, the field level security boxes are tiny and low contrast, so it’s hard to tell which Edit boxes are grayed out and which you want/need to click. It's hard enough for me. I have no idea how people with vision problems are able to use this interface.]
I’m going to be honest here: I just checked every single box on every single object. In theory I should consider the purpose of each field and decide whether this permission set needs read or edit access to it. But that would take forever. It’s just not reasonable in this context. It’s one thing to carefully consider field level security by user persona as you create a new field or three, but it’s exponentially more difficult when you are talking about all fields on all objects at once.
4. Don’t forget to also give visibility into the object’s tab, if applicable. Admittedly, the integration user probably doesn’t need the tab visibility, as it doesn’t use the UI, but I think it’s worth the click now, while you’re already here, in order to make this a permission set you can use for people in the future.
5. Similarly, assign all record types to this permset. Again, any given integration might need only one or two record types, but if this is going to be the basis for a permset used by humans later, they’re probably going to need them all. Save clicks later by making this The Big Full Access Permset. It will be easier later to narrow things.
6. When you’ve done this for every object your integration user (or future humans) might need, you can stretch out your mouse hand and reward yourself. 🧁
My method was to open the Object Settings and option-click a dozen or so objects into new tabs. Then I went through the tabs clicking Edit on each. Then I worked my way down the line of tabs doing all the clicking, saving, then closing that tab. When I ended up back at the objects list, I refreshed, then started again from the bottom-most object that needed access but didn’t have it yet.
You may want to listen to a podcast or music while you’re doing this mostly-mindless clicking work. 🎧
Pro Tip: Work on a permset that is not yet part of a permission set group. That will allow you to save much faster. Permsets that are in groups need extra time to process a save because the permset group also recalculates. I found that if my permset was in a group I couldn’t really work in different tabs because I was faster than the recalculation.
Further discussion:
I just described creating a single master permission set. In theory it would be better to create permission sets either for single objects or at least clusters of objects that go together for individual bits of functionality and then to group those into a permission set group. But as I think I’ve said multiple times, “Who has the time?”
Building permsets up like that is great in theory and may be workable as you are implementing a brand new org, but it’s unrealistic when you’re talking about an org that’s already in use and a small Salesforce admin team. If you want to just get integration user licenses working, this is the baseline for how you can do it.
It's Worth It
This is clearly a ton of work to get set up the first time. But remember that you're laying the groundwork for a user management and security transition you have to make in 2026. Plus you're getting to use free integration users and save your paid (or granted) licenses only for people!
