Feed

Hello, @Aine Byrne

  yes, in CRM Analytics, you can hide widgets when using certain global filters, even if those filters don't apply to widgets. 

1.Disable Global Filter for the Widget-Edit the widget in the dashboard designer go to its properties and uncheck 'Apply Global Filters'.This stops the widget from reacting to the global filter. 

2. Set up a binding to control the widget's visibility. In the dashboard JSON, add a binding to the widgets 'hidden' property.For Example, if the global filter selects a value that should hide the widget, use a condition like 

{{cell(filterStep.selection,0,'value').asString()=='someValue'}} to set 'hidden':true. 

3 . Apply the global filter and check if the widget hides as expected. Adjust the Binding logic if needed.

Hi Polly, 

The difference there is because there's not a direct connection in PMM between the Session Status field and the creation of Service Delivery records: the Track Attendance component is an efficient tool because it does both steps - creating the Service Deliveries, and updating the Session Status - but they are still technically separate steps that aren't inherently linked, so just updating the Session Status doesn't create Service Delivery records. 

(For examples, one advantage of having the two steps separated could be if I wanted to update a Session to the Competed status to say that staff were present during the time of the Session, but not create any Service Deliveries because no one came). 

If you wanted to make it so that just updating the Session Status automatically created Service Deliveries for Service Participants in the associated Schedule, I believe the best way you could accomplish that would be with a Record Triggered Flow along these lines:

• Object: Service Session
• Condition: Status = Complete (only when a record is updated to meet the entry conditions)
• Get Records: check if there's any Service Deliveries already on that Session
• Decision: only continue to next steps if there are not already Service Deliveries found in the previous step (to prevent duplication)
• Get Records: Service Participants on the same Service Schedule as the Session
• Loop: loop through the Service Participants assigning Service Delivery values for each and then assigning those Service Deliveries to a Record Collection Variable.
• Create Records: create the Service Deliveries

Try this validation rule that enforces the MFN_review_completed__c picklist field as required.

AND(
    ISPICKVAL(StageName, "Considering"),
    ISPICKVAL(StageName, "Deciding"),
    ISPICKVAL(StageName, "Committed"),
    ISPICKVAL(StageName, "Investing"),
    ISPICKVAL(StageName, "Invested"),
    ISPICKVAL(StageName, "Lost to competitor"),
    ISPICKVAL(StageName, "Business Withdrew"),
    ISPICKVAL(StageName, "Client Withdrew"),
    ISBLANK(MFN_review_completed__c),
    RecordTypeId = "01220000000AOd6AAG"
)

AND(

RecordTypeId = "01220000000AOd6AAG",

ISPICKVAL(MFN_review_completed__c, ""),

OR(

ISPICKVAL(StageName, "Considering"),

ISPICKVAL(StageName, "Deciding"),

ISPICKVAL(StageName, "Committed"),

ISPICKVAL(StageName, "Investing"),

ISPICKVAL(StageName, "Invested"),

ISPICKVAL(StageName, "Lost to competitor"),

ISPICKVAL(StageName, "Business Withdrew"),

ISPICKVAL(StageName, "Client Withdrew")

)

). Makes sure you copy the correct recordtype and use the correct values for picklist field

Check out these options if helps. 

In Salesforce, when a case is reopened, it is essentially reactivating an existing record, and certain fields, including Case Type, might not automatically get reset or re-populated unless explicitly handled by processes, workflows, or triggers.  

If you want the Case Type field to be automatically populated when a case is reopened, consider setting up a Workflow Rule to check if the case status is set to "Reopened" or a similar status, and then update the Case Type accordingly.  

If there are Field Updates or flows involved with setting the Case Type, they may not be triggered upon reopening a case because Salesforce considers reopening as a status change rather than creating a new record.  

Field Update on Case Status Change: Review your Field Update actions to ensure they also trigger when the Status is changed to "Reopened". If needed, adjust the criteria for the field update to account for this specific scenario.  

Another possibility is that the Record Type of the case might have been changed when it was reopened, which could affect the visibility or default value of the Case Type field. 

Check for Record Type Change: If the Record Type is changing upon reopening (e.g., from "New" to "Reopened"), check if different Page Layouts or default field values are associated with the new record type. Ensure the Case Type field is still visible and populated correctly in the layout for the reopened cases.