Let’s pickup from yesterday’s challenge. The conceptual answer is to create a state machine.
What is a state machine?
According to Wikipedia, “A finite-state machine (FSM) … or simply a state machine, is a mathematical model of computation. It is an abstract machine that can be in exactly one of a finite number of states at any given time. The FSM can change from one state to another in response to some inputs; the change from one state to another is called a transition. An FSM is defined by a list of its states, its initial state, and the inputs that trigger each transition.”
Given this, the next step in the design process is to take the mega-complex “if.. then” from yesterday and document it in a FSM diagram. Below is an example, where “Sx” represents the state and “Tx” represents the trigger to move to the next state.
Mapping this in this type of diagram ensures you have covered all possible states and all possible transitions, along with the trigger that initiates the transition.
Also, since it’s visual, it’s easier for the client to approve the design before you build it.
You have a few options to construct this in Salesforce. Several readers responded to the challenge and recommended using custom metadata and flows/triggers. Basically, I agree with this approach.
However in this scenario, I ended up using a custom object and flows. Custom metadata is great, but I tend to only use it for more hardcore data modelling, as the UI is not as friendly as a custom object. Also, there are limits to which data types you can use in custom metadata.
The takeaway
To implement a statement machine in Salesforce, a custom object recorded the current state along with the trigger that caused the transition. Flows performed the actual transition and updated the custom object. The object was agnostic enough to be used with multiple target fields.