Transition Rules

Transition Rules

You can create transition rules to govern how and when a record moves from one status to another. Use them to enforce your own business rules — what must be true before a status change is permitted, and what action must be performed while it happens — so that every user follows the same standardized process.

A transition rule is defined for a specific pair of statuses (a From Status and a To Status) within a module. When a user attempts that status change, Zoho FSM evaluates the rule. If the conditions aren't satisfied, the action is blocked until the required changes are made in the record.

Here are a few examples:
  1. Don't schedule without a serviceable address - Blocks scheduling until the address and contact number are complete enough for a technician to reach the site.
  2. Discount ceiling before dispatch - Prevents dispatch when the discount exceeds the approved limit, catching margin exceptions before a resource is committed.
  3. High-value jobs need a documented scope - Requires a written scope on large-value appointments before anyone travels.

Available in Editions: Professional, Premium

Info
Permission Required: Transition Customization
Find out the Edition-specific limits for Transition Rules.

Supported modules 

  1. Requests
  2. Estimates
  3. Work Orders
  4. Service Appointments

Components of a Transition Rule  

Basic Information   

Specify the following details:
  1. Name: A name to identify the transition rule.
  2. Description: A short explanation of the transition rule.
  3. Choose Module: The module the transition rule applies to.
  4. From Status: The status the record is in when this rule will be applied.
  5. To Status: The status the record will move to after the transition.

Before Criteria 

These conditions must already be true on the record for the transition to be offered at all. If they fail, the action button is disabled and the user cannot begin the transition.

Transition Forms 

These are evaluated when the user initiates the transition. Each Transition Form has its own criteria, and the tasks inside it are presented to the user only when that criteria is satisfied. Within a Transition Form, the criteria decides whether the form applies, and the tasks decide what the user must fill in before the transition can complete.

Create a Transition Rule  

A sample transition rule has been used to explain the steps involved in creating one. This transition rule stops appointments from being dispatched with an address the technician can't actually reach or a customer who can't be contacted for confirmation.  
  1. Navigate to Setup > Process Flow > Transition Rules and click Add Transition Rule.
  2. In the New Transition Rule popup, provide the basic information and click Next.



  3. Add the Before Criteria.
    1. Click the Add [] icon to add a new condition.
    2. In the first dropdown, select a field.
    3. In the second dropdown, select the operator.
    4. In the third dropdown, enter the value to compare the selected field against.
    5. Use Edit pattern to modify the logic of the conditions you have added.
    6. Select the appropriate logical operator (AND / OR) from the options displayed between the conditions.
    7. Use the Delete [] icon to remove a criteria.



  4. Add the Transition Form.
    Add the tasks that must be completed. A task makes a field or an action mandatory before the transition can finish.
         - Click Add Field.
         - To make a field mandatory, choose Fields, select the field, and click Proceed.
         - To make an action mandatory, choose Notes, Service Report, or Job Sheets, and click Proceed.
           The Service Report and Job Sheets options will be available only for the Service Appointments module.



    Next, add the criteria that must be met.
         - Click Add Criteria or the Add [] icon.
         - Select a field, an operator, and a value, exactly as you did for the Before Criteria.
         - Use Edit Pattern to adjust the condition logic, and choose the logical operator for combining conditions.



    Transition Forms are applied in the order in which they are added. You can reorder [] them by dragging, minimize them to tidy the view while you work, and delete any you no longer need.
  5. Click Save.
Info
Points to remember  
  1. A maximum of 50 transition rules can be created per org.
  2. Only one transition rule is allowed per From Status and To Status pair, per module.
  3. You can add a maximum of five Before Criteria per transition rule.
  4. You can add a maximum of five Transition Forms per transition rule, with up to five criteria in each.
  5. These are the Task limits per Transition Form:
    1. Requests, Estimates, Work Orders: 5 fields + 1 Note
    2. Service Appointments: 5 fields + 1 Note + 1 Job Sheet + 1 Service Report
  6. Transition Forms are evaluated in the order they are arranged.
  7. If your Zoho FSM account is downgraded, transition rules you have already created will continue to exist and will still be applied. However, you will not be able to edit them.
  8. Zoho FSM has a set of default transition rules that are available out of the box. All these will be listed in the Transition Rules page. E.g. the transition rule that prompts users to add a note when terminating a Request.

How Transition Rules Are Applied

Once a transition rule is saved, it is evaluated automatically every time a user attempts the status change it governs. No further action is needed to activate it.

The evaluation happens in two stages. First, the Before Criteria are checked against the record as it currently stands. If any condition fails, the action that would trigger the transition is disabled, and the user cannot begin the transition at all. Second, if the Before Criteria pass and the user initiates the transition, the Transition Forms are evaluated in order. Each form whose criteria are satisfied is presented to the user, who must complete its tasks before the status change is committed. If a required field, note, service report, or job sheet is left empty, the transition cannot be completed.

Example  
Consider the transition rule created in the previous section, which is designed to stop appointments from being scheduled with an address the technician cannot actually reach or a customer who cannot be contacted for confirmation.

When this transition rule comes into effect, the Dispatch button is disabled for any service appointment that is missing its address details or phone number. The user cannot proceed until the missing information is supplied — for example, by updating the phone number on the record. Once the record satisfies the Before Criteria, the action becomes available and the transition can continue.



This behavior is identical in the mobile app.


Enforcement Across Linked Records

Records in Zoho FSM are related — a work order is the parent of its service appointments, for example. Because a child record's status change often drives the parent's too, and vice versa, transition rules are evaluated across that relationship rather than in isolation. If a transition rule exists for a parent record, it is triggered — where applicable — during a child record's transition as well. This means a user completing a service appointment is held to the work order's rules simultaneously.

There are different scenarios in which this occurs.
Scenario 1: The parent record's task appears during the child's transition
When the parent module's transition rule includes tasks, those tasks are presented to the user alongside the child record's own tasks. The user completes both sets in a single flow.



This behavior is identical in the mobile app.



Example: You add a transition rule for In Progress → Completed on both the work order and the service appointment. When a user completes the service appointment, the work order's transition rule is shown as well, alongside the appointment's own transition rule. The user therefore satisfies the requirements of both records without having to navigate to the work order separately.
Scenario 2: The parent record's Before Criteria is evaluated 
When a transition control exists on the parent module, its criteria are evaluated as soon as a transition is applied on the child record — not later, when the parent is closed out. This ensures the user learns about the parent's requirement at the moment they are working on the record, rather than discovering it after the fact.

If the parent's criteria are not satisfied, an error message is displayed within the child record, stating which condition has not been met. The user has two ways forward:
  1. Cancel: exit the message, address the parent record's requirement immediately, then return to the child record and apply the transition again. By this point the parent's criteria are satisfied, so the transition proceeds without interruption.
  2. Continue: continue with the child record's transition and leave the parent's requirement to be resolved later. The condition is not discarded; it is recorded against the parent record so that it can be picked up when the parent is next worked on.


This behavior is identical in the mobile app.


If the criteria is not met, this is indicated in the parent record, and it is captured in the parent record's timeline as Unmet Conditions. This gives you a durable record of which requirement was outstanding and when.



This behavior is identical in the mobile app.



Once edits are made to the record so that the condition is satisfied, the Proceed option appears in the parent record in place of the error that was previously shown, and the parent's transition can go ahead.



This behavior is identical in the mobile app.



Example: You have added transition rules for In Progress → Completed on both the work order and the service appointment. For work orders, the Before Criteria is that the work order cannot be completed unless it has been invoiced. When a user completes the service appointment, the rule for the work order is triggered too. If the work order has not yet been invoiced, the unmet condition is recorded on the work order's timeline; once the invoice is raised, the work order can be completed.
Scenario 3: Canceling or Terminating a Record
In the case of Canceling or Terminating a record, if there are unmet criteria in an associated record, then you will not be allowed to proceed further unless the criteria has been satisfied.



Example: You have added transition rules for Any → Cancelled on work order. When you try to cancel a linked Request and the Before Criteria in the work order is not met, then the request cannot be cancelled either.

Enforcement Across All Entry Points

Wherever a status change can be triggered, the transition rule is applied. This includes the key action buttons such as Complete, and also indirect paths such as line items and time sheets. A user cannot bypass a rule by changing the status from a different part of the product.

Existing Transition Settings  

If you have already enabled settings such as Service Report required for SA completion or Job Sheets completion required for SA completion, these are listed under Transition Rules, so you have a single place to review every rule that governs a status change.

Manage Transition Rules  

From Setup > Process Flow > Transition Rule, you can view all the transition rules created for your org and Edit [] and Delete [] them: