#Salesforce Labs8 debatiendo

Because Dashboard Pal is a free Salesforce Labs application rather than an officially supported commercial product, it does not have a dedicated direct support email on the AppExchange. Instead, Salesforce Labs tools are community-supported. Here are some options for support: 

1. Post here on the Trailblazer, like you already have. 

2. Open a Salesforce support case, but remember that you may not get help because it is a Salesforce Labs appL 

https://help.salesforce.com/s/case-submission

 3. Since many Salesforce Labs solutions are open source, you can check the 

Dashboard Pal GitHub Repository to log issues, view pull requests, or inspect code components regarding API versions. 

Hi there, 

There is a tracked issue on

: "Einstein Analytics - Adoption App - Apex Error Argument cannot be null," which describes the same WaveMetaDataQueueable class failing after installing the Analytics Adoption Metadata package. The exact error text differs slightly from yours (Argument cannot be null vs. the ApexPages.addMessage context error), but it's the same failing queueable class in the same managed package — worth checking that issue thread for current status/comments, since it confirms this isn't isolated to your org. 

Since the package is managed and WaveMetaDataQueueable's source is hidden, you're right that you can't patch around it directly. Practical options in the meantime: 

1. Disable the Adoption Metadata dataflow trigger. In Setup → Analytics Settings (or via the AnalyticsSettings metadata, analyticsAdoptionMetadata flag), you can turn off automatic Adoption Analytics metadata collection so the queueable stops firing and throwing the exception on schedule. 

2. Check/upvote the existing issue on

rather than filing a duplicate — that's the channel Salesforce Labs teams actually monitor for prioritization, and comments/votes there carry more weight toward getting a fix scheduled than a community thread. 

3. If this isn't business-critical for you right now, uninstalling the package until a patch lands is the cleanest way to stop the recurring failed async job/error emails. 

Since it's a Salesforce Labs (not core platform) managed package, there's no formal SLA on a fix — the

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