4

Salesforce is going to rollout this security change: https://help.salesforce.com/s/articleView?id=005132365&type=1&utm_source=techcomms&utm_medium=email&utm_campaign=FY26_Core_4013001

We have a managed package that is accessed from external API through connected app. So I can see the CONNECTED_APP_NAME in Setup -> Connected Apps OAuth Usage and I see Install button for it.

We want to avoid asking our users to click Install for it and put our Connected App to the managed package components. We did it for beta to try, and after upgrading the package version to the beta version I see CONNECTED_APP_NAME in the Setup -> Manage Connected Apps. Now, in the Setup -> Connected Apps OAuth Usage I see Uninstall beside the name, BUT I get duplicate records in Setup -> Manage Connected Apps.

enter image description here

Is it a way to NOT see the duplication? For the clean package installation it works fine: we login to sf, allow the usage and the connected app from managed package appears already installed (as expected), the problem is only in upgrades.

UPDATE:

I have replicated the flow on three different orgs and on the one in the initial question (after reinstalling the package and upgrading it again), no more duplications: also connected app appears to be installed after upgrade of the package to the version, where connected app is inside the components.

2 Answers 2

2

So I am going through the same thing (as a customer). While there does not seem to be a way to automate the install of a Connected App, you do have the ability to insert SetupEntityAccess records to make sure during an API Access Control cutover from Self-Authorized to Admin approved users are pre-authorized, you can ensure there won't be a drop in connections (automatic revoking of Access Tokens / Refresh tokens).

Here is a rough script of what I am using to insert these records before cutover:

OauthToken[] oaList = [ SELECT LastUsedDate,AppMenuItemId,AppName,User.Profile.Name,User.ProfileId FROM OauthToken WHERE User.IsActive = true AND LastUsedDate = THIS_YEAR ORDER BY AppName ]; Set<Id> profileIds = new Set<Id>(); Set<String> connAppNames = new Set<String>(); for(OauthToken oa : oaList){ profileIds.add(oa.User.ProfileId); connAppNames.add(oa.AppName); } 

From there, you can set query for each result set:

//API Access Migration Anon Apex Script ConnectedApplication[] cAppList = [ Select Id,Name From ConnectedApplication WHERE Name IN: connAppNames ORDER BY Name ASC ]; PermissionSet[] permSetList = [ Select Id,Name,Profile.Name,ProfileId From PermissionSet WHERE ProfileId IN: profileIds ]; 

And then these two result sets allows to insert SetupEntityAccess records

//This holds what Profiles/PermissionSets have access to which ConnectedApplications //Instead of being selective for the cutover, we will apply all profiles to all //Connected Applications for the cutover. Once we verify everything is still working, //we can re-query and slim down what profiles have access to which ConnectedApplications SetupEntityAccess[] seaListToInsert = new SetupEntityAccess[]{}; for(ConnectedApplication cApp : cAppList){ for(PermissionSet permSet : permSetList){ //Add a row for each ConnectedApp/PermissonSet(Profile) combo SetupEntityAccess sea = new SetupEntityAccess(); sea.SetupEntityId = cApp.Id; sea.ParentId = permSet.Id; seaListToInsert.add(sea); } } //insert seaListToInsert; 
7
  • 2
    Unfortunately, that's not the case for us, because we want to leave access as All users may self-authorize, so we have explicit approve from each user for our external API to access the sf org. However, upvoting the answer, because it may help others too. Commented Aug 21 at 14:43
  • 1
    This is ok as customer but definitely not as a managed package provider..As a managed package provider you want to ensure your admin know about your app Commented Aug 21 at 14:44
  • @MariiaIllarionova right thats true, but during the install, if they want to switch to Admin Pre Approved, this can be useful Commented Aug 21 at 14:44
  • 1
    Oh, somehow I haven't noticed it the first time, but it appears installed automatically after upgrade, without clicking Install (this time). Looks like if the user accepts all managed package components, the app with the same client_id is left as duplicate but is considered installed now. Commented Aug 21 at 14:47
  • 1
    This drives me crazy, on the third org there are just no duplications, on the 1st - install still persists, on the 2nd - duplications but no need for install. Such inconsistency -_- Commented Aug 21 at 15:21
2

There is no solution for this as this can create a security hole for the organization that is installing your app.Letting org admin know about this is ethical practice.

Best strategy is to work with org administrator where you want install to happen, establish trust and have them install your app.

1
  • 1
    Understood, hoped to avoid communication, because it actually asks the user after login if they want to grant access for our connected app and with which permissions, but sound reasonable. Thank you! Commented Aug 21 at 14:36

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.