#CRM Configuration65 discussing

Removing Assign label Standard button from case of One APP A1 , it removes other app also . do we have any workaround to remove for single app A1 specific, not for A2,A3 app. I have MF, AIF, PMS and other apps . when i removed Assign label from AIF app it removes from all the apps.  

Do we have limitations org wide for list view.  

 or

Is there any workaround or configuration available in Salesforce to remove the standard Assign button for a single application (A1) only, without impacting other applications (A2, A3, MF, PMS), when all applications share the same Case object and do not use separate record types?

Hi @SRK M you need to create the field as a part of previous challenge Get Started with Picklists. Here it is mentioned how to add the "Macaron Flavor" field. Make sure you complete this challenge as well

I can't re-create this issue in any of my Salesforce orgs.   

If the Case Record Types have no default value assigned, the Case: Origin field defaults to blank as expected when creating a new Case using the standard button.     

The only way it defaults to a "pre-selected" value is if I set it on the Case Record Type, or on the "New Case" Global Action, or Object-Specific Quick Action

HI @Mounika Teegapuram

, 

The image outlines a common challenge when using the Salesforce

Since Agile Accelerator is a managed package, its core UI components (like the Sprint Board) are often "locked," meaning you cannot easily inject a custom record type picker directly into the "New Task" button without significant custom development.

Here is a breakdown of how to approach these requirements.

1. Task Type Selection (Record Types)

The Challenge: The "New Task" button on the Agile Accelerator Sprint Board is designed to quickly create a standard Task record. It does not natively trigger the standard Salesforce Record Type selection screen.

Recommended Approaches:

• The "Low-Code" Workaround (Screen Flow): Instead of using the native "New Task" button, create a Global Action or a Quick Action that launches a Screen Flow. The Flow can ask "Is this a Bug?" and then create the task with the correct Record Type. You would place this button in the utility bar or at the top of the page, though it won't live inside the board's white space.
• The "Pro-Code" Approach (LWC Override): You could build a custom Lightning Web Component (LWC) that wraps or replaces the task creation logic. However, since the Sprint Board is part of a managed package, you cannot easily modify the internal "Add" button code. Most teams choose to train users to create Bugs via a separate tab or global action.

2. Visual Differentiation (Color Coding)

The Challenge: The Agile Accelerator Sprint Board has limited styling configurations. It typically displays tasks as uniform cards.

Recommended Approaches:

• Formula Fields with Images: While you can't easily change the background color of the card, you can add a Formula Field to the Task object that displays a small traffic light or icon based on the Record Type (e.g., a red circle for Bugs).
  • Implementation: Go to Task Fields -> New Formula (Text) -> Use the IMAGE() function.
  • Display: Ensure this field is added to the Compact Layout for Tasks, as Agile Accelerator often pulls fields from there to display on the card.
• Custom CSS (Not Recommended): You could technically use a "Lightning Bolt" or a browser extension to inject CSS to color cards based on text strings, but this is brittle and will break during Salesforce updates.

3. Known Limitations & Considerations

Before you dive into heavy customization, keep these Agile Accelerator constraints in mind:

• Managed Package Constraints: You cannot modify the underlying Apex or Javascript controllers of the Sprint Board. Any "seamless" integration usually requires building a fully custom board, which is a massive undertaking.
• Field Mapping: Ensure that your new "Bug" Record Type still contains the mandatory fields required by Agile Accelerator (like Sprint, Status, and Work) or the tasks won't appear on the board at all.
• Syncing: If you use a separate object for Bugs (instead of just a Record Type on Tasks), they will not show up on the Sprint Board unless you write a trigger to sync them to the Task object. Sticking to Record Types on the Task object is the correct path.

i think you would need to use DLRS and have it run scheduled. because if it is a normal rollup that only runs on edit of the child opp then if there are no opps changed in 6 months the value on the account would be stale since it wouldn't have recalculated.

You can read the below documentation on DLRS. This is a really powerful tool that is managed by the salesforce.org team 

https://www.salesforceben.com/guide-to-salesforce-dlrs-declarative-lookup-roll-up-summaries/

Installation Link:

https://install.salesforce.org/products/dlrs/latest