1. Transition API
2. Workflow API 
3. Custom Functions in Workflows.
   

Step 2 - Define the Process Flow in the Blueprint Editor

1. In the Blueprint Editor, drag and drop all the States (stages) that form a part of the process.
   
   
2. Establish the process flow between the States by connecting the nodes in the State buttons. Note that the Start State is the equivalent of "None" value of the chosen picklist field.
   
   
3. Create Transitions by clicking on the + button between two States. To delete a transition, simply Right Click on the transition line and click Delete Transition. 
   

The white buttons in the Blueprint represent States in the Blueprint (Deal Stages). The green buttons represent Transitions (Conditions required to complete each stage). Each Transition you configure is displayed as a button on the record's details page.

To complete a Transition, click on the Transition button and execute the actions mentioned in the ensuing popup window. On successful completion of the Transition, you will move to the next State in the Blueprint.

For example, clicking on Check warranty will open a pop-up window, which will guide you through executing this transition.

Save a Blueprint as a Draft

1. While accepting to take up the repair, it should be ensured that the estimated duration of the repair does not exceed seven days.
2. As soon as the Accept Repair transition is executed, a call should be made to the mechanic to whom the repair job will be assigned.
   

Before Transition:

Define Criteria that dictate exactly when this Transition should be available for the records in a process. Example criteria: "Repair plan accepted is True". In this case, the Transition will be shown to records only when the Repair plan accepted? field is updated to True. If you have no such conditions, you can skip the criteria section. In such a case, the Transition will be visible on all records right away. 

During Transition:

This section guides the Transition owners in completing a particular stage in a process by prompting them to enter specific fields, notes, attachments and other information contextually. For example, while accepting a repair, it needs to be ensured that the contact details of the customer have been captured. In such a case, all these details can be mandated in the During Transition section of the Accept Repair Transition.

Following are the details that you can mandate in the During Transition section:

1. Mandate and validate fields across modules
2. Include checklists
3. Mandate Associated Items
4. Add a message to Transition owners
5. Make notes mandatory
6. Make attachments mandatory
   

1. Mandate and validate fields across modules:

You can guide users to enter information required as part of your process by mandating fields at the appropriate stages. These could be fields from the primary Blueprint module or related modules (using lookup field). For example, during the Accept Repair transition, you can mandate the Customer Name, Phone and Email fields.

To mandate fields of the Blueprint module and related modules:

1. In the During Transition tab, click Add.
2. Choose the required module from the drop-down list.
3. Select the field to be mandated. Repeat this action for the number of fields required. 
   
   
4. Validate fields to ensure that the user enters acceptable values. Here, the estimated duration of repair should not exceed 7 days from the date of accepting the repair. 
   
   

1. Abide by the guidelines mentioned in the organization's repair SoP.
2. Get plan reviewed by supervisor.
   

1. In the During Transition tab, click Add.
2. Select Checklists.
3. Add a title for the checklist and the list of To-do items. 
4. This will be displayed to the selected Transition owners. Only when the Transition owner "checks off" these items from the list, will he/she be able to proceed to the next State in the Blueprint. This gives you a solid, clear picture of progress of each stage.
   

3. Mandate the Creation of Associated Items

Apart from fields and checklists, you can mandate the creation of the following items:

1. Tasks
2. Events
3. Calls
4. Quotes
5. Sales Orders
6. Cases
   

For example, once the repair has been accepted, a task could be assigned to the mechanic who would take up the repair and also a call should be made to the mechanic.

To mandate the creation of associated items:

1. In the During Transition tab, click Add.
2. Select Associated Items.
3. Choose from the Associated Items dropdown list: Tasks and Calls.  
   

4. Add a message to Transition owners

You can include messages to users at each stage, so that every Transition owner knows what's expected of him/her. 

To add a message to the Transition owners:

1. In the During Transition tab, click Add.
2. Select Message.
3. Write a suitable message in the text box. 
   

5. Make notes mandatory

You may want to know additional details about various aspects of a process, such as when a user categorizes a repair as Severe, they can add a note detailing the reasons for labelling it so. These additional details could be added as notes - and these notes could also be mandated in the During Transition stage of a process.

To make notes mandatory, in the During Transition tab, select the Make Notes as Mandatory checkbox.  While executing the Severe transition, the transition owner will be required to enter details of the repair as notes, as outlined in the message.

6. Make attachments mandatory

Any process, be it sales, insurance, manufacturing or real estate - any business process for that matter brings with it the need for several documents. Sales contracts, Service Level Agreements, Legal Documents and so on are required at different stages of a process. You can mandate them at the required stage in a Blueprint.

To make attachments mandatory:

In the During Transition tab, check the Make Attachment as Mandatory checkbox.  While executing the Severe transition, the transition owner will be required to attach the documents that support the reasons for categorizing a repair as Severe. You can reorder the items to be displayed in the popup window by using the UP and DOWN arrows. 

After Transition:

1. Send Email Notification
2. Assign Tasks
3. Make a Field Update
4. Trigger Webhooks
5. Trigger Custom Functions
6. Convert Record (Applicable for the Leads and Quotes modules) 
   

In our example, a task should be created so that the bill is generated after the Complete Repair transition. So, choose Tasks and add the necessary conditions. 

Similarly, you can build conditions for each Transition until the end of the process.

Common Transition

A Common Transition is a Transition that can be executed from all States in a process. 

For example, in a Deal follow-up process, you typically know if you have won or lost a deal after the record goes through several stages such as qualification, negotiation, discount approval and so on. So Deal Lost is a Transition that is available only towards the end of the process. But assume that a customer shows no interest and you want to drop a deal at the Qualification stage itself. In such a case, you must be able to execute the Deal Lost Transition right then - rather than go through all the intermediary stages. 

To make this possible, you must make Deal Lost  a Common Transition by selecting the checkbox as seen in the following image. Once you do, you will see the Deal Lost transition on all States. 

Automatic transitions

Automatic Transitions are available in Vertical Solutions in early access mode.

Automatic transitions help you combat process delays. Often, a record that traverses through a process tends to stagnate in a particular state and you may not even realise it. This causes unwarranted delays. One thing you can certainly do is set an SLA for the state and be notified whenever there's an escalation.

But ultimately, SLA is also a notification or a task/field update of sorts— the record at the end of the day, needs your manual intervention in order to progress further in the process. If you only want to be notified of escalations, you may configure SLAs. On the other hand, if you want the system to act and automatically move a record from one state to another at any point, you can now create automatic transitions.

What are automatic transitions and how do they work?

An automatic transition is one in which a record in a Blueprint automatically moves from one state to another, after a specified "Wait" time has elapsed.

As per the process, in order for a record to go from State A to State B, you will have to perform a Transition A. If this Transition A has not been executed within a said time period, say, 5 days, then the Automatic Transition configured for that state will get executed and the record will be pushed forward automatically to another state in the Blueprint as per the configuration.

For instance, in the following screenshot, the system will wait for one of the transitions to take place: Either "Confirm Interest" or "Drop deal". If no action is taken on this record until a said date, the record will be moved to the "Price Quote" stage automatically and the users can take it up from there.

To configure an automatic transition:

Select the Automatic Transition checkbox as you create a regular transition.

1. Add a new Blueprint: The new blueprint will be effective only based on it's state (active/inactive).  It will apply to records created or modified after the upgrade, based on the blueprint’s state (active/inactive).
2. Modify a Blueprint: Updates to a blueprint will impact only records created or modified after the upgrade.  The Records that are associated with the modified blueprint at that instant will either remain in, or move to the current version of Blueprint.
1. Add a New State: If a record is in State A, and the previous version of the blueprint had State B as the next step, but a new State C is introduced between A and B, the record will transition to State C (reflecting the updated version).
2. Edit a State: Any changes made in the developer console will be reflected in the subscriber’s org. Records will automatically move to the latest version of the blueprint.
3. Delete a State: If a record is in State A and that state is deleted with no available transitions, the record will remain under the blueprint's process, but its primary field will become uneditable. The record will not exit the blueprint.
4. Transitions: All changes made to the blueprint’s transitions in the developer console will be reflected in the subscriber’s organization. Records will follow the updated transition rules based on the current version of the blueprint.
3. Delete a Blueprint: The Blueprint will be removed from the subscriber account and all the associated records will be dis-associated from it.