#Appexchage Apps23 diskutieren mit

@Ankit Shrestha full access on LabsActionPlans__ActionPlan__c is not the check that failed. That message is Lightning hiding an access or deleted-record error inside the delete.

Action Plans V4 does not only delete its own row. The delete trigger also removes the Tasks the plan created. If one of those tasks, or the record the task hangs off, blocks the delete, the whole save fails and you get this generic line. A validation rule or a trigger on Task is enough. Sys admin on the plan object does not bypass that.

No line in the log usually means the trace flag was not on for your user when you clicked delete. Set a flag for yourself, Apex at finer, delete one plan, and read the DmlException. The real object is in there.

A lookup set to restrict deletion throws a different message, the one that names the related record. If you only see the permission text, start with the tasks, not with another perm set on the plan.

Support is right that they do not own this package. The delete path is in the public Salesforce Labs repo you already linked. Once the log names the task or the parent record, that is the fix, not more access on Action Plan.

@Josh Wiseman

I’d treat this as a package-maintenance issue first rather than just looking for a replacement.

If Dashboard Pal is unmanaged/older Labs code with components below the required API version, I’d check whether the package is still actively maintained before investing time in an alternative. If it isn’t, a small custom Lightning solution may actually be easier to maintain long term.

@Aira Gutierrez

I’d separate the two errors first rather than troubleshooting them as one issue.

For utam is not defined, I’d verify the UTAM compile step is actually generating the page objects before running WDIO. Then check the generated output and package path for salesforce-pageobjects. If the generated JS isn’t there, changing the import path won’t fix the underlying problem.

Hi Anuj!

For an AppExchange Security Review, having the pen-test and documentation already prepared should give you a good starting point. For the remaining work, I’d look for someone who has hands-on experience with Salesforce’s security review questionnaire, code/security remediation, and the reviewer communication process. 

It may also be worth having the consultant do a pre-submission review of the package and security documentation before the June 9 submission, so any gaps can be addressed beforehand. 

If anyone here has recently supported an AppExchange Security Review end-to-end, their experience with the questionnaire and review process would be especially useful for Anuj.

Hi Aron!

Based on Salesforce’s current AppExchange security-review guidance, your use case appears to fall under the packaging requirement.

For an Authorization Code/Web Server flow where the callback URL is controlled by the ISV partner, Salesforce currently lists the integration as requiring packaging. The fact that the SaaS application itself isn’t installed in subscriber orgs doesn’t by itself remove that requirement. 

Also, Salesforce is moving new integrations toward External Client Apps (ECA). Existing Connected Apps can continue to operate, but Salesforce recommends ECAs for new integrations. 

So I would clarify with the reviewer whether they specifically require the existing Connected App to be migrated to an ECA, rather than assuming the four requested controls can all be enabled on the existing Connected App. Salesforce documents ECA-specific OAuth security controls such as refresh-token rotation and IP restrictions.

For the security-review response, I’d also explicitly describe your OAuth flow, who owns the callback URL, where refresh tokens are stored, and how PKCE/refresh-token protection is implemented. That should make it easier for the reviewer to confirm the expected configuration.

Hi Jeff!

Your setup looks close to the supported packaged-ECA model. Salesforce documents that a packaged External Client App can either generate its own OAuth global settings in the subscriber org or reference the global OAuth settings from the source/packaging org. In the latter model, the subscriber ECA’s OAuth link should reference the source org and its consumer ID. 

So I wouldn’t expect the subscriber to automatically need a separate consumer key just because the package is installed. Salesforce specifically documents the source-org global-settings association for OAuth. 

One thing I’d verify is the actual ExtlClntAppOauthSettings OAuth link in the installed subscriber app and confirm it points to the source org/global OAuth settings exactly as documented. If the subscriber instead has its own global settings, then it will have its own OAuth consumer credentials. 

Also, the source org needs to remain available because subscriber ECAs that reference its global OAuth settings depend on that source configuration. 

Given that your OAuth request is reaching the consent page and then specifically fails with OAUTH_AUTHORIZATION_BLOCKED, I’d focus on the ECA association/global OAuth configuration rather than the subscriber policy alone. 

If you can share the ExtlClntAppOauthSettings OAuth link value from the packaged ECA/subscriber, that would be the next thing I’d check.

For an AppExchange Security Review, I’d avoid designing around the assumption that an API-only user automatically bypasses every authentication control. The safer approach is to confirm the current review-team requirements for integration credentials and test the exact OAuth/API flow in the submitted environment beforehand. If automated scanners require interactive authentication, Salesforce Partner Support or the Security Review team should clarify the supported testing arrangement rather than relying on manual OTP handling.  Visit here for more information.

This looks like a mismatch created by Salesforce's own PKCE enforcement rollout rather than something wrong in your org's configuration. The SalesforceDX Namespace Registry connected app is a Salesforce-owned system connected app used by the Namespace Registries Link Namespace flow, and its PKCE requirement is locked because Salesforce has been moving connected apps and External Client Apps toward mandatory PKCE, with no admin opt-out on system apps like this one. Your org-level Require PKCE toggle being off is not relevant here, since that setting only affects apps that inherit the org default, and this one has its own requirement baked in. 

The "invalid_request / missing required code challenge" error means the client side of this OAuth exchange, the Link Namespace popup itself, is not sending a code_challenge parameter even though the connected app now demands one. Since that popup is Salesforce's own UI and not something you control from Setup, you cannot fix this from your Dev Hub or Namespace org settings. Other admins have hit the same "missing required code challenge" wall on various Salesforce-owned OAuth flows since PKCE enforcement tightened, so this is worth logging as a Salesforce Support case, quoting the exact error and the Dev Hub and Namespace org IDs, so they can confirm whether it is a tracked regression tied to the PKCE rollout on that specific connected app. 

Background on PKCE enforcement:

Assumption: I cannot reproduce your Dev Hub, so I cannot fully confirm this is a Salesforce-side defect versus something specific to your org's Namespace Registry setup. This is inferred from the well-documented PKCE enforcement pattern and other reports of the same error on Salesforce-managed connected apps once PKCE became mandatory without an opt-out.