Leverage layout rules to customize workflow

Leverage layout rules to customize workflow

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

    • Sticky Posts

    • Tip #28 - Plan less and deliver more using WIP limit in Zoho Sprints

      Hello, It's been a while since we met with a quick, interesting tip. As the saying goes, "Too much of anything is good for nothing", today the focus is on delivering your outcomes with the right amount of planning. Your plan should be practical, calculative, and achievable for driving a qualitative success.    Laura's plan   Laura has a habit of planning her project deliverables before assigning work to her team-mates. Once the plan is finalized, she schedules a general meeting with her team and

    • Tip # 3- Working on the Scrum board

      Continuing from our Tip #2 on leading to a sprint, let's see how to manage the work items on the Scrum board.  Once you start the sprint your work items are automatically displayed on the Scrum board where you will actually manage the work items. It is a snapshot of the backlog items identified for the current sprint.    The layout of the Scrum board Simply put, the scrum board is just like a physical board with sticky notes on which the work items of the active sprint are displayed.  The scrum board

    • Tip#2- Leading you to a Sprint

      Product Backlog After the user stories are written and finalized, they are sorted to create the Product Backlog for the project during the Backlog Grooming meeting. This is a master list of all the work items that have been identified for the project and sorted by priority. Requirements are not constant during this period.The Product Backlog is dynamic and is an ongoing process. Every user story in the Product Backlog is customer centric. The Product Backlog includes: User centric stories based on

    • Tip #1- Why swimlanes?

      Lanes define a clear path to reach your destination. In Agile, swimlane is one such concept that sets a simple and clear process of the work that you do.   The concept of swimlane can be related to the pool, where the swimmers gather in their respective lanes to start off. Similar to the pool, work items are grouped in different categories. Each category is referred as a lane and is displayed in horizontal format. Swimlanes are effective in categorizing the work items with respective to specific