IdeaExchange

Hi Logan!

If this is the standard SPIFF Leadership Dashboard tile, the ranges shown in “Attainment Tracking by Rep” are generally driven by the dashboard/component configuration rather than being editable directly from the tile itself.

I’d check the underlying dashboard/report or CRM Analytics dataset for the logic defining the attainment bands. If those thresholds are hard-coded in the managed content, they may not be directly customizable.

If you can share which Salesforce product/package the SPIFF Leadership Dashboard comes from and whether you have Edit access to the dashboard, we can narrow down where those 95% / 100% thresholds are being defined.

Hi Pete,

If you’re referring to Sales Engagement cadences, I’d first check whether the cadence target/activity data is exposed through the standard reporting objects in your Salesforce edition and configuration. Some cadence metrics, especially email opens and clicks, may not be available as standard report fields even though they are visible in the Sales Engagement UI.

I’d also verify that the user has the required Sales Engagement permissions and that email tracking is enabled for the relevant emails.

If the targets are visible in the cadence UI but not available in Reports, sharing which object/report type you’re using and which specific fields you’re trying to report on would help determine whether this is a reporting limitation or a configuration issue.

Hi Colleen, 

If the Gift Commitment designation split is percentage-based, rounding can definitely create a difference between the intended whole-dollar allocation and the amount calculated for each designation. 

As a workaround, you could consider capturing the donor-intended dollar amounts separately and using automation to calculate the designation percentages from those amounts, with one designation absorbing any rounding remainder so the final allocated amounts always equal the original gift amount. 

For example, for a $100 gift split as $33, $33, and $34, the system could calculate the percentages but explicitly assign the remaining $1 to the final designation rather than relying on independent percentage rounding. 

However, if the designation split amount is what ultimately feeds the GL and payment reconciliation, I’d be cautious about changing those values through unsupported automation. It would be worth confirming whether your current Nonprofit Cloud/Gift Management version provides a supported way to override designation split amounts. 

If anyone has implemented a supported dollar-based allocation or reconciliation workaround for this scenario, that would be useful to compare.

Hi @Amine ASLI, 

As of now, Open a Page in a Screen Flow has limitations in the Salesforce Mobile App. The action is designed to open Salesforce or external pages in a browser, and some navigation methods available in Lightning Experience aren't supported in the mobile app. 

For a mobile use case, I’d recommend exposing the Screen Flow through an object-specific Flow Quick Action instead. This is an officially supported way to run Screen Flows in the Salesforce Mobile App. 

Regarding whether Salesforce will expand Open a Page support for mobile, I haven't seen an official Salesforce roadmap or ETA confirming that yet. It would be best to follow the relevant IdeaExchange idea for future updates. 

Please Check Below Link: 

 https://help.salesforce.com/s/articleView?id=000382253&type=1&utm

Hope This Helps!!

Hey Charlotte, 

Web-to-Lead/Web-to-Case auto-response rules not firing when records are created via the REST API (which is likely how your Form-to-Case integration inserts records). This is actually a REST API limitation, not specifically tied to the Salesforce Integration license itself, the SOAP API has an EmailHeader option to explicitly trigger auto-response, but REST API doesn't expose an equivalent. 

Two documented workarounds: 

Option 1: A Workflow Rule that fires on Case creation and sends the email directly, no code needed, simplest option, but as you noted, means managing logic in two places. 

Option 2: A single Apex trigger using Database.DMLOptions to explicitly re-trigger the existing Auto-Response Rules: 

```apex 

trigger AfterCaseInsert on Case (after insert) { 

    if (trigger.isAfter && trigger.isInsert) { 

        List<Case> newlyInsertedCases = [SELECT Id From Case WHERE Id IN :trigger.new]; 

        Database.DMLOptions autoResponseOptions = new Database.DMLOptions(); 

        autoResponseOptions.EmailHeader.triggerAutoResponseEmail = true; 

        for (Case c : newlyInsertedCases) { 

            Database.update(c, autoResponseOptions); 

        } 

    } 

} 

``` 

This re-updates each new Case with a DML option that explicitly triggers your existing Auto-Response Rules, so you keep managing rules in one place (Setup > Auto-Response Rules) instead of duplicating logic in Flow. This runs regardless of which user/license created the record, since it's the DML option itself that flags the update to trigger auto-response, not something dependent on the inserting user's license type. 

Worth testing in a sandbox first, and for high case volume, this should be refactored to Queueable/future to avoid governor limit issues on bulk inserts. 

Reference: