#Appexchage Apps18 人がディスカッション中

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.

@Usman Khan

You might be right, but in my last communication with the Security Review team, they clearly mentioned that we need to have the waiver code.  

Please keep us update; As Usman suggested please raise a case from your partner account.  

Hi @Janaki Reddi

A few native options actually cover garden style ticketing well timed/dated admission tickets, guest checkout (no login needed for buyers), and Salesforce native data (no sync lag or external ticketing database). Here's how the leading ones stack up:

Two things worth confirming before you commit, since they change the recommendation: 

• Ticket volume/pattern is this timed/dated admission (e.g. "Saturday 10am garden entry") with capacity caps, or more traditional single events (fundraisers, classes, weddings)? Blackthorn and AC Events both handle capacity based timed tickets; EventSpark leans more toward simple RSVP/registration.
• Budget tier Blackthorn is licensed per-org and sits mid-to-high; EventSpark is the lower cost native option if this is a smaller garden with modest ticket volume.

If you want, I can pull current AppExchange reviews/pricing details for whichever one fits your volume, or scope out what a native build/config would take if you'd rather not add a managed package at all worth knowing that's also an option here, since garden ticketing with capacity limits is buildable on standard Salesforce (Flow + Experience Cloud + a payment gateway like Stripe) if you want full control instead of a packaged app. 

I hope you find the above information helpful. If it does, please mark it as Best Answer to help others too.

Hi @Kalaiarasi Rajendhran The installation is likely failing because the package creates additional dynamic dashboards, causing your org to exceed the allowed limit. Even after reducing your existing dashboards, the package may still require more dynamic dashboard slots than are available. Check your org's dynamic dashboard limit and the package documentation to confirm the number of dashboards it installs. If you need standard dashboards instead, see if the package provides an alternate version or contact the package owner, as the dashboard type cannot be changed during installation.