
Layout rules in Zoho Sprints primarily aim to customize the field layout of your creation forms to meet complex requirements. But it doesn't stop there. Its customization can push the boundaries of how your fields behave, how data is gathered, how processes are branched out, and how workflow is channeled.
Based on conditions, you can tailor field behavior, direct the life cycle of an item, mandate specific actions, restrict the field options, or auto-assign users. The possibilities are aplenty.
We've tried to provide a few sample scenarios that help you automate your data collection and progress tracking flow. If you have any specific requirements, please state them in the comments, and we'll find out if layout rules can help you.
Use case 1: Restricting item statuses based on work item types
With layout rules, each item type can have its own workflow. This means it can have its own unique set of statuses that align with its specific lifecycle.
Let's assume you have three item types: Bug, Story, and Task.
Each type follows its own lifecycle, represented by the following statuses.
- Bug goes through the To Do, In Progress, Bug Fixing, Bug Testing, and Done statuses.
- Story has To Do, Ideation, In Progress, Development, Review, and Done.
- And Task moves through a simple To Do, In Progress, and Done.
To align with these flows, certain statuses should not be available to specific item types. For instance, a story or a task should not be moved to the Bug Fixing status. Similarly, a bug or a task should not be moved to the Development status.
To enforce this, we can create layout rules that control which statuses are available based on the item type.
So, we'll create three conditions with each item type as the primary field.
- If the item type is Bug, specify the condition with the trigger action to restrict the status pick list to To Do, In Progress, Bug Fixing, Bug Testing, and Done.
- If the item type is Story, specify the condition with the trigger action to restrict the status pick list to To Do, Ideation, In Progress, Development, Review, and Done.
- If the item type is Task, specify the condition with the trigger action to restrict the status pick list to To Do, In Progress, and Done.
Together, these conditions control the status progression for each item type. So, when you create a bug, it will only progress into the statuses that belong to the Bug lifecycle.
Use Case 2: Restricting future statuses based on the item's current status
When your team requires a pre-defined strict workflow where an item can be moved from a specific status to only a few statuses, layout rules can help implement this. For example, an item in the Bug Fixing status should only move to Bug Testing, and no other status. This way, each status controls the next status in the workflow.
To ensure this, create layout rules specifying conditions for each of the item status:
- If the status is To do, specify the condition with the trigger action to restrict the status pick list to In progress and Rejected.
- If the status is In progress, specify the condition with the trigger action to restrict the status pick list to In progress and Development.
- If the status is Development, specify the condition with the trigger action to restrict the status pick list to Review Level 1.
- If the status is Review Level 1, specify the condition with the trigger action to restrict the status pick list to Reopen and Review Level 2.
- If the status is Reopen, specify the condition with the trigger action to restrict the status pick list to In progress.
Use case 3: Making a field mandatory based on item status or item type
Let's assume you want a field to be made mandatory only when the item is moved to one particular status. Which implies the field will remain non-mandatory during other statuses and will be mandatory only at that particular status. So, the progress to that status must be allowed only when the mandatory field is updated.
For instance, when an item is moved to the Done status, the Approver field must become mandatory to record completion approval. To ensure that this process is executed, you can create a layout rule where the primary field is the Status Name. If the status field is updated to Done, specify the condition with the trigger action to set the Approver field as mandatory.
Use case 4: Showing or hiding a section or field based on item types
Layout rules enable you to show or hide fields or sections based on item type conditions.
Let's say a section with fields related to a new feature should only be visible when the item type is New Feature.
Similarly, when the item type is Security Issue, the section with fields related to Security issue must be visible.
To achieve this, create a layout rule with Item Type as the primary field.
- Create a condition for the New Feature item type with a trigger action to show the New Feature Details section.
- Create a condition for the Security Issue item type with a trigger action to show the Security Issue Details section.
Use case 5: Selecting specific assignees for item types and priorities
Layout rules can help you assign users based on the item type and priority. Let's say your team has a group of developers with varied levels of experience and expertise. You want to assign the high priority items to a more experienced member like John, while assigning low priority items to a novice like Peter.
If the item type is Bug and the priority level is Critical, you can assign the bug to John. If the priority level is High, it goes to Peter.
To meet this requirement, you can create a layout rule with Item Type as the primary field.
- Create a condition for the item type Bug with a subcondition where the priority level is Critical and the trigger action has the Set Field Value Assignee as John.
- For the same condition, add a subcondition where the priority level is High and the trigger action has the Set Field Value Assignee as Peter.
Similarly, say you want the Task item type with a medium priority level to go to Helen, and a low priority level should go to James.
- Create a condition for the item type Task with a subcondition where the priority level is Medium and the trigger action has the Set Field Value Assignee as Helen.
- For the same condition, add a subcondition where the priority level is Low and the trigger action has the Set Field Value Assignee as James.
These are just a few examples of how layout rules can streamline your project management. Do you have any particular scenario that needs resolution? Please share it with us.
Thanks,
Zoho Sprints Team