3

This level of detail isn't covered in documentation, so I figured it was worth raising (especially in case I'm wrong!).

I know that generally speaking this license type is restricted to API only work. But the Named Credentials metadata type is directly relevant to API integration. Yet when we attempt to make a callout with a user with an Integration only license, we get an error suggesting the named credential doesn't exist.

Error message: The callout couldn't access the endpoint. You might not have the required permissions, or the named credential "{XXX}" might not exist

We got this despite assigning the permission set granting access to the named credential to the user. This seems to be sufficient to get another fully-licensed user to be able to make the callout.

We're going to transition off of the Named Credential to creating a Custom Setting to hold the API endpoint / auth info instead.

5
  • 1
    The integration user license is designed for inbound integration use, as far as I am aware, while named credentials are for outbound use.
    – Phil W
    Commented Jun 1, 2023 at 18:06
  • But why would that license be only for inbound integration? For example, our integration user is making callouts to Salesforce which in turn trigger callouts to an external org, which ties it back to the user.
    – smohyee
    Commented Jun 2, 2023 at 19:11
  • A transaction running as the integration user, initiated through an inbound request, could, in principle, initiate a callout itself - that is true. But clearly it is an API only account which means for inbound calls. I guess the usage pattern you are trying is not supported.
    – Phil W
    Commented Jun 2, 2023 at 19:24
  • Yeah that seems to be the case. Figured I'd make the post so other people could see it too.
    – smohyee
    Commented Jun 19, 2023 at 16:18
  • Sure. Why not post a self-answer and get some reps!?
    – Phil W
    Commented Jun 19, 2023 at 17:04

2 Answers 2

3

I believe this can work so long as you make sure to enable access to the User External Credentials Object. I ran into the same error when trying to trigger a flow in response to an Integration Licence user updating data.

Granting a permission set to the user that provided External Credential Principal Access was not sufficient, but also granting Access to the User External Credentials object seems to have done the trick.

2
  • Thanks, this worked. Just note that the Permission Set should NOT have a license type specified. If you specify the "Salesforce Integration" license type, then the "User External Credentials" object is not available. Leaving license type blank fixes this but still allows the PS to be assigned to your integration user.
    – Ben
    Commented Apr 30 at 22:47
  • That extra permission of Read access on Object Settings > "User External Credential" object did the trick
    – compski
    Commented Jul 23 at 9:23
1

For anyone else who has ended up here:

  1. Yes, it does appear to be true that Named Credentials are not accessible to users with the free 'Salesforce Integration User' License.
  2. No, it's not a big deal. Named Credentials is just a handy new way to specify a callout endpoint and its auth params in a standardized way, but it's not required.
  3. Instead, you could create a Custom Metadata or Custom Settings item that stores the same info, and have your code access that instead of a Named Credential. Or you can even neglect best practices and hardcode that info directly into your apex class.
3
  • this is disappointing; if the inbound user needs to do a callout; then rather than store auth params less securely, the logic should delegate to a Platform Event which can run in the context of a different user (that is, unless Integration User Licenses can't publish Platform Events - I have not checked). Also, is this still true in Summer 23 (e.g. Named Principal Access)?
    – cropredy
    Commented Jun 22, 2023 at 17:24
  • I believe we tested this in our sandbox that was on the Summer 23 preview, so yes to that question. The Platform Event idea is a good one, although I bet you're right that they won't have access to that either.
    – smohyee
    Commented Jun 26, 2023 at 18:06
  • named credential access (pre-Summer 23 and what you said in OP) is distinct from named principal access (Summer 23); just checking :-)
    – cropredy
    Commented Jun 26, 2023 at 21:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .