Enhanced Path

Install In Production

Install In Sandbox

Details

Aims to replicate and further extend the functionality of the SF native Path component. Features:

1. Works with any picklist field on any object and any record type
2. Syncs Key Fields and Guidance for Success from native SF Path Settings using the Metadata API
3. Dynamically resolves infinite levels of nested dependent picklist fields using LDS
4. Allows the admin to choose if users can hide/collapse the Key Field and Guidance for Success panel during configuration on the Lightning Record Page/Flexipage
5. Allows the admin to prevent backwards movement of the picklist field during configuration on the Lightning Record Page/Flexipage
6. Can define additional requried depdendent fields for X picklist value using the DependentFieldNames__c field, as well as optional fields using the OptionalFieldNames__c field on PathAssistantStep__c records
7. Can define a flow to launch when a user attempts to change to X pickist value using the RunFlow__c and FlowApiName__c fields on PathAssistantStep__c records, allowing for pre-commit validation
8. Can show confetti on successful update to X picklist value using the ShowConfetti__c field on PathAssistantStep__c records
9. Can group picklist values together to show as the last step on the path using the IsGrouped__c field on PathAssistantStep__c records and define if they are considered "lost" (causing them to render as red on the path instead of green) using the IsLost__c field
10. Detects Nebula Logger and logs errors using it if present

Setup Information

Video guide coming Soon™

1. After installing, schedule the ScheduleQueueableSyncPathAssistants job (I use every hour, but you could do whatever makes sense for your Org)
2. Run the QueueableSyncPathAssistants job once manually (or wait for your scheduled job to run) to sync all existing Path Settings to the PathAssitant__c and PathAssistantStep__c objects (anon apex snippet: System.enqueueJob(new QueueableSyncPathAssistants()))
3. Assign the included Enhanced Path Admin and Enhanced Path User permission sets out to relevant users
4. Create or update any PathAssistant__c and PathAssistantStep__c records to configure any additional functionality for desired object + record type + picklist field combinations

PathAssistant__c records have an external id field which is used for querying and upserting, the expected format is: ObjectAPIName_FieldAPIName_RecordTypeAPIName (so for example, Lead_Status___MASTER__)

PathAssistantStep__c records also have an external id field, the expected format concatenates the picklist value to the parent PathAssistant__c's external id: ObjectAPIName_FieldAPIName_RecordTypeAPIName_PicklistValueAPIName (so for example, Lead_Status___MASTER__Converted - Business)

Flow Input/Output Details and Overriding Toast Messages

1. LWC always passes the same inputs to flow, these cannot be customized. They are 5 text variables and the expected names are: newValue, oldValue, fieldApiName, objectApiName, and recordId
2. The toast that is sent when a flow finishes can be controlled and customized using a boolean flow output variable named enhancedPathOverride and setting it's value to true. To customize the toast title, message, and variant use flow text output variables named toastTitle, toastMessage, and toastVariant (see lightning-toast specs for list of variants)

NOTE: There's a gotcha when using a combination of fault paths, subflows, and flow output variables:

Make sure you set your output variables before the last screen the user sees if you're passing to subflows (especially if in a fault path), otherwise your output variables may not have the proper values passed back to the LWC. To account for this, I have a screen node at the end of all my flows that houses another LWC that automatically navigates the user past that screen, so that my outputs are always refreshed.

How I Use This

I have a "router" flow for each object where I use the Enhanced Path component. I then configure my PathAssistantStep__c records to have each picklist value where I want to perform some pre-commit validation using flow launch into this router flow.

In that router flow I then get the full record based on the recordId passed in, then make decisions based on things like Record Type, newValue, and oldValue to determine what subflow a user should be passed to when attempting to update X field on Y object to Z value. I'll then typically pass the full record around to the subflows to prevent further queries. At the end of the router flow and/or subflow I include an update node to set the picklist value to the newValue as the LWC will not update the picklist after passing off to a flow.

Feature Requests Are Welcome!

Feel free to submit any feature requests or bug reports as issues on the repo, or if you're interested in contributing code, submit a PR! I built this for my own use but am happy to share it with the community and make improvements as needed.