#Appexchage Apps26 diskutieren mit

@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.

Hi Ravi, 

This is a hard platform limitation, not something specific to this package's install options — formula fields (including LEN() and any other function) simply cannot reference a field with Shield Platform Encryption enabled, regardless of encryption type (deterministic or probabilistic). There's no install mode, package version, or config toggle that can bypass this, since it's enforced at the metadata/formula-compilation level by the platform itself, not by the package. 

Answering your questions directly: 

1. No install option can exclude Phone from the formula while keeping the field itself unchanged — the formula field's definition is fixed at package build time. Since it's a Salesforce Labs package (community-supported, not a vendor with a support team), there's no "encrypted-field-safe" variant to switch to; you'd need to modify the metadata yourself post-install (see #2). 

2. Yes — this is your real path forward. Since this is an unmanaged or lightly-managed Labs package (most Labs apps are), you should have edit access to the Data_Quality_Score__c formula after install. Deploy the package, then immediately edit that formula field to remove the LEN(Phone) reference (or rebuild the scoring logic to exclude Phone entirely). If the package is a managed package and the field is locked, you won't be able to edit it at all — worth confirming which type it is before installing. 

3. Apex can read encrypted field values only if the running user has "View Encrypted Data" permission — it does NOT bypass encryption for everyone, and even Apex referencing encrypted fields in a SOQL WHERE clause or certain operations has platform restrictions (you can query and return encrypted field values to permitted users, but can't do things like LIKE filtering on ciphertext for probabilistic encryption). So an Apex/Flow version could work for LEN()-style logic, but only for users granted View Encrypted Data — it's not a clean drop-in replacement without also managing that permission carefully. This isn't something you can get "from the package" as-is; it'd require custom rebuilding of the Data_Quality_Score__c logic in Apex. 

4. This is a well-known Shield Platform Encryption conflict for any formula field on Account/Contact.Phone or similar PII fields — anyone using Shield Encryption commonly hits this with any AppExchange package (Labs or paid) that includes formula fields referencing standard PII fields. The typical resolution is exactly what's in #2: install, then manually rebuild/adjust the offending formula fields to exclude the encrypted field, since there's no vendor-side fix that works universally across different customers' encryption configurations. 

Practical recommendation 

Since this is a Labs package (no formal support team, as you may already know from prior threads on this), your fastest path is: 

- Check if it's managed or unmanaged (Setup > Installed Packages, or check the AppExchange listing type) 

- If unmanaged: install, then edit Data_Quality_Score__c to remove the Phone reference and replace it with a non-encrypted proxy (e.g., checking Phone <> null via a different mechanism, or scoring based on other non-encrypted fields only) 

- If managed and the field is locked: you likely can't fix it directly — you'd need to clone the package's dashboard/report logic into your own custom fields that reference a non-encrypted proxy field instead

Hi Kavya, 

It seems you are trying to install this in Sandbox if I am not wrong. 

So you need to click on tryIt button then only you will be able to install in Sandbox.