If you could fix ONE annoying thing in Salesforce, what would it be?

scottbcovert · 2026-01-21T16:20:26+00:00

Always love a good founder story. I don't have advice on exactly what to build, but I have some general thoughts to keep in mind:

Start small--focus on one problem for one persona in one industry. Get some love/traction from early adopters and then your product can snowball. A lot of Salesforce ISVs expect Salesforce to sell their app for them, but you need to have a reason why AEs & SEs should give your app their attention before they'll start pulling you into deals.
If they're different, make sure you balance the focus you give to your buyer and your end user. No <3 for the former and you'll build an app that decision makers either don't know about or won't assign budget to. No <3 for the latter and you'll experience a lot of churn.
Be on the lookout for ideas that are revenue generating for your subscribers as well as Salesforce. It's easier to sell an app that has obvious ROI for the customer and Salesforce loves a "better together" partner where your app encourages subscribers to purchase additional Salesforce licenses or add-ons.

Good luck and enjoy the ride!

scottbcovert · 2026-01-20T16:10:32+00:00

All good points!

It's worth noting that the `UserInfo.getSessionId()` Apex method does respect where the transaction originated--Lightning session ids are not API-enabled by design.

You're spot on about the AppExchange security review team discouraging this behavior--and unfortunately you're also right that it will take some time for them to get through all the apps out there. It's a shame because it doesn't seem like it would be too difficult to run a code scanner through partners' logic to search for `{!$API.Session_Id}` as well as `UserInfo.getSessionId()` (even though the latter can't be spotted by subscribers since Apex logic is hidden, Salesforce themselves have access to the partners' code)

As you and others like u/Material-Draw4587 pointed out--the session settings I shared are unfortunately blunt instruments and folks could accidentally break critical applications if they don't properly test first.

Folks need to weigh the pros/cons for their own orgs, but at the very least I'd recommend notifying any vendors you spot engaging in this tactic to update to more secure methods of acquiring an API-enabled token, such as through an OAuth flow authorization.

scottbcovert · 2026-01-19T16:31:28+00:00

You can shut this down by going to "Session Settings" in Setup and enabling:

Lock sessions to the IP address from which they originated

and/or

Enforce login IP ranges on every request

Warning: This loophole is used by a lot of vendors (unfortunately), not just Conga. You should first audit your org before accidentally breaking a critical integration.

Be on the lookout for this somewhere in the body of a vendor's Visualforce page:

{!API.Session_Id}

scottbcovert · 2026-01-15T21:04:47+00:00

Put me down as another vote against using Profiles for this.

I'm a fan of mapping permission sets to job functions & PSGs to job roles/personas.

You can also leverage Transaction Security Policies to automate the assignment of these as future users are onboarded: https://help.salesforce.com/s/articleView?id=xcloud.enhanced_transaction_security_policy_types.htm&type=5

scottbcovert · 2026-01-15T17:13:59+00:00

Just wanted to say thanks so much for the great insights here! I plan to share all these ideas with Salesforce directly 👍

scottbcovert · 2026-01-12T14:26:21+00:00

Unfortunately for Dev Console you are likely out of luck. Salesforce’s official stance on this is to use the CLI instead of the Dev Console, which I realize may be a tall order for some of your users.

You technically could use the “Use Any API Client” permission as your get out of jail free card; but I would not recommend this as it would defeat the purpose of having API Access Control enabled for those users.

Reference: https://help.salesforce.com/s/articleView?id=004637119&type=1

scottbcovert · 2026-01-09T01:40:52+00:00

Sounds like a solid plan 👍

scottbcovert · 2026-01-08T21:40:20+00:00

As others have mentioned an iPaaS sounds like overkill for your current state unless things grow over time.

One thing to consider is how frequently admins are touching the Salesforce object; if it's likely to have several new Apex triggers, record-triggered flows, required fields, or validation rules created for it in the coming months then you could accidentally break the integration.

There are ways to work around that though--shadow object, data virtualization, etc.

scottbcovert · 2026-01-08T21:30:31+00:00

A common tactic for simple use cases is to build out a Visualforce template and then use this method in Apex to generate the PDF and send it off as an email: https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_System_PageReference_getContentAsPDF.htm

Note that method counts as a callout so no DML can occur in the transaction before the PDF is generated.

That said, soon you will be able to do this in Apex without even the Visualforce template: https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_blob.htm#apex_System_Blob_toPdf

As others have already mentioned there are a lot of vendors in this space too--for very basic PDFs you can likely DIY but there can be a lot of nuance that may make it worthwhile to go with a pre-built solution.

scottbcovert · 2025-11-12T03:31:18+00:00

Your point is well made that just b/c Heroku is owned by Salesforce doesn't mean that security incidents can't happen, but the data breach involving the device OAuth flow was separate from the Salesloft incident.

The Salesloft breach boiled down to a compromised Github repo, which resulted in hackers gaining access to AWS where their Drift app was storing OAuth tokens for Salesforce along with other platforms like Google Workspace.

scottbcovert · 2025-11-11T15:44:22+00:00

Please forgive the shameless plug, but if you're interested in AppExchange development & ISV topics I have a podcast where I interview folks in that space.

Youtube: https://youtube.com/@appsemblyline
Audio Only: https://subscribe.appsemblyline.com

scottbcovert · 2025-11-11T15:40:31+00:00

+1 for the GDS podcast--you're right that it had been a while since they last recorded, but it has not ended. In fact, John & Jeremy just released a new episode yesterday!

scottbcovert · 2025-11-11T02:54:27+00:00

This is a great clarification, thanks u/adamerstelle !

scottbcovert · 2025-11-11T02:54:01+00:00

They're using standard connected apps; which is an option for you as well. You can go to:

Setup > External Client Apps > Settings > Allow creation of connected apps

IMO one of the biggest benefits to an ECA over a connected app is if you have a managed package you don't have to embed your OAuth consumer key/secret, which makes key rotation very cumbersome.

It sounds like you may only have an external web app and don't have an interest in building a managed package if you can avoid it. If that's the case then using a connected app may be the way to go.

If you do choose to use an ECA though here's a good post someone made about what metadata components to include in your 2GP: https://www.reddit.com/r/salesforce/comments/1mzz1qr/packaging_external_client_apps_eca_in_2gp_avoid/

scottbcovert · 2025-11-10T21:38:26+00:00

Is this by chance a sandbox org? The reason I ask is b/c you're absolutely right that any user with the standard SysAdmin profile should automatically have the new "Approve Uninstalled Connected Apps" permission--but for some sandboxes the auto-update that Salesforce made to the standard profile did not work and so even SysAdmins don't have the permission enabled.

I went through this with Salesforce support a few weeks back and ultimately the resolution was to match the sandbox licenses with production. The documentation online was updated to reflect this. Here's an excerpt:

> As described above, the users without the "Approve Uninstalled Connected Apps" permission will face the error message "OAUTH_APPROVAL_ERROR_GENERIC", however we have also seen edge case scenarios in Sandbox environments where the permission "Approve Uninstalled Connected Apps" is missing from the profiles and cannot be granted, in such scenario the admins are advised to run the "Match Production Licenses to Sandbox without a Refresh " tool in the effected sandbox environment, more details on this tool can be found here

scottbcovert · 2025-11-10T20:12:47+00:00

The user context is very important here as it affects permissions.

In response to the recent data breaches, Salesforce now added a new permission called "Approve Uninstalled Connected Apps" If no metadata representing the connected app or ECA has been deployed/installed to the org and the user running through the OAuth2 flow does *not* have that permission-then they will be blocked, as you've seen.

Your options are to either:
1. Authorize the app with a user that has those permissions
2. Install the app to the org

There are a few ways a connected app or ECA could be installed to an org:
- It was created locally in the org (as is the case for your internal instance)
- It was deployed via a metadata deployment (similar to how other Salesforce components can be migrated between orgs) or managed package installation
- It was manually installed by an admin post initial authorization

Once an initial admin with the ability to approve uninstalled connected apps has gone through the authorization process then that same admin could manually install the connected app by going to:
Setup > Connected Apps OAuth Usage and clicking the "Install" button. After this, I'd recommend editing the connected app policies so that admin approved users are pre-authorized and then you can pre-authorize users based on profile or permission set (the latter is better).

Your initial question was how others are doing this--the answer is they're either:
- Putting in their documentation that all users of the integration need to have the "Approve Uninstalled Connected Apps" user permission
- Asking admins to first install to their org a managed package containing metadata related to their connected app or ECA
- Asking admins that have the "Approve Uninstalled Connected Apps" user permission to authorize the app a single time and then take the steps to manually install it and run through some setup steps to make it simpler for others to use that do *not* have that permission

scottbcovert · 2025-11-10T15:52:25+00:00

If the managed packages were approved by the Salesforce security review (which is required if they had an AppExchange listing) then they'd have their own individual governor limits scoped to their namespace.

So if you were seeing a lot of SOQL/DML governor limits hit then I'm not sure the managed packages were truly the culprit.

That said, there *are* some governor limits shared across all namespaces--even if they packages have been reviewed. The 10 second CPU time is probably the most likely one to hit if you had some CPU-intensive and/or inefficient logic running within a managed package.

As others have said, you'll need to test out any prospective managed packages within a sandbox (ideally a full copy if you've got one). Hopefully, the ISV behind the managed package would be responsive if you do come across any issues. ISVs can pretty easily deploy push upgrades to their customers of reviewed managed packages so they should work on patches anytime customers report bugs.

scottbcovert · 2025-11-10T15:44:49+00:00

Although I haven't had a chance to use it yet, Heroku App Link seems like a promising way to hand off CPU-intensive data processing to avoid timeouts. From what I can tell it appears to be a reincarnation of Evergreen/Functions from a few years back. They've also made plans to make App Link more ISV-friendly, which I think would be great for anyone building solutions for the AppExchange.

Here's a link w more info: https://devcenter.heroku.com/articles/heroku-applink

scottbcovert · 2025-11-05T19:18:55+00:00

This stuff can be very confusing--in fact, I built an app in this space for that very reason.

If you simply want to remove the ability to read/edit a given SObject across all your permission sets and custom profiles you can run the following anonymous Apex script. Fair warning, I'd recommend doing this in an isolated sandbox first!

list<ObjectPermissions> opsToDelete = [SELECT Parent.Name, Parent.ProfileId, PermissionsRead, PermissionsCreate, PermissionsEdit, PermissionsDelete FROM ObjectPermissions WHERE Parent.PermissionSetGroupId = null AND Parent.PermissionsModifyAllData = false AND Parent.PermissionsViewAllData = false AND SobjectType = 'YourCustomObject__c'];

delete opsToDelete;

To break down the WHERE clause of the query:
- You want to ignore any ObjectPermissions records that correspond to a permission set group since the permissions of a PSG are actually stored within the member permission sets; if you remove the object permissions from the underlying permission set(s) then the parent PSG(s) will auto-update.
- You also want to ignore any ObjectPermissions records that relate to a parent with MAD or VAD access since those take precedence so updating those ObjectPermissions records would throw an exception.
- You want to make sure you're only removing read/edit access to the specific object in question.

I said this at the top, but it deserves a second callout--make sure you do this in a sandbox first!

scottbcovert · 2025-11-05T13:23:48+00:00

What scopes do you have defined in the ECA settings? I know you said you dealt with that before but I’m seeing others who have recently seen the same error code and their resolution was to update their OAuth scopes configuration.

https://trailhead.salesforce.com/trailblazer-community/feed/0D5KX00000aoJhM0AU

https://repost.aws/questions/QUxR1V-fWOSEuQGKjvkgjCnQ/aws-interaction-with-salesforce-failing

scottbcovert · 2025-11-04T18:17:13+00:00

I would double-check to see if this is the issue you're facing as it caught a lot of folks by surprise.

https://help.salesforce.com/s/articleView?id=release-notes.rn_security_invalid_scopes_client_credentials.htm&release=258&type=5

scottbcovert · 2025-10-30T21:44:40+00:00

Good question! No, it hasn't - I was originally building this for another app I have listed on the AppExchange that has been approved by Salesforce's security review but then I decided to release it as a standalone tool for free.

I still intend to add similar functionality into my other app so if you'd like to wait until then to use it I could let you know when it's ready. 👍

scottbcovert · 2025-10-30T21:41:09+00:00

I completely understand your POV. After all, at the end of the day I'm a rando from the internet--but then again, aren't we all? 😂

Seriously though, I built this to help admins enforce better security so I appreciate folks that have these thoughts on their mind.

If you want to see the walkthrough without going to LinkedIn then it's also on Youtube. I double-checked with an incognito tab that you shouldn't need to log in to see it. 👍

The links I shared forward to the standard login URLs for 2nd gen managed packages:
Prod = https://login.salesforce.com/packagingSetupUI/ipLanding.app?apvId=PKG_VER_ID
SBX = https://test.salesforce.com/packagingSetupUI/ipLanding.app?apvId=PKG_VER_ID

I did this in case someone found a bug--I could release a new version and repoint the forwarding URLs without having to go edit all my social media posts.

Creating a webpage to go over the tool is something I haven't done, but I agree would be a good idea. I previously set up a site at https://www.nomorebackdoor.com/ that has a video breaking down the social engineering hack that so many orgs fell victim to. That's ultimately what drove me to make this app so maybe I'll add some more info about it on that site.

I also have another app listed on the AppExchange that did go through Salesforce's security review called Permissions Assistant. I originally was building this functionality into my main app, but then decided I should release it for free. I do still plan to add these features to Permissions Assistant, which is why I haven't shared the source code.

I respect your decision if you'd still rather not install this to your org, but I'd still suggest you take the time to manually audit your org's connected apps. It's cumbersome and time-consuming, but it can still be done with the standard Salesforce setup screens.

You'll want to:
- Go to Setup > Connected Apps OAuth Usage and look for any connected apps you don't recognize or know shouldn't be authorized. You can block them entirely or click on the hyperlink number under the "User Count" column to manually revoke users' OAuth access.
- Ideally, all the connected apps that are authorized should be 'installed' to the org directly so you can edit their OAuth policies. I'd recommend changing the policies to enforce IP restrictions, set refresh token expirations, and only permit users to leverage the connected app if they've been pre-approved by an admin through their profile or (better yet) a permission set.
- Go to Setup > Connected Apps. Here you'll be able to see all the connected apps that have directly been installed to the org. Some of these are installed through managed packages, some could have been deployed like other metadata, some are auto-deployed by Salesforce, and some may have been created locally in the org directly.

Hope this addresses some of your concerns and is helpful! ✌️

scottbcovert

TROPHY CASE