🎨 UX Design: Workflow Automation
This issue tracks the design work for the parent epic .
Working prototype
Persona
Non-technical project managers and scrum masters
MVC Priorities
- Simple and intuitive UX for the first time, non-technical users
- Extensible layout to cover workflow use cases beyond Project:Plan
- Essential CRUD functionalities
UX Definitions
Automation Management
Automation management
A set of features dedicated to managing automations. Managing automations is achieved through a list view at the group/sub-group and project level, with the ability to see critical details related to all automations for that area.
Automation filters
Users can filter the automation list by defined variables; state, status, trigger, and tags. Users can also use plain text search to locate an automation by name.
Automation state
Enabled or disabled. This can be defined when creating the automation or can be toggled from the automation list.
Automation status
- Valid: The automation is recognized by the system as valid and has not encountered an error.
- Invalid: The automation is not recognized by the system and/or has encountered an error.
- Incomplete: The automation is missing a required component, trigger, and/or action and cannot be run. When an automation is disabled, its status will revert to incomplete in the list until it is enabled.
Automation scope
The scope of groups/sub-groups and/or projects the automation applies to.
Automation details
A summary of the automation, including; state, status, description, scope, trigger, condition(s), action, and history. This information is viewed in a drawer format from the automation list screen.
Automation history
A timestamped list of user activity related to the automation. Created, edited, enabled, and disabled events are tracked here. Automation history is accessed through the details drawer.
Log
A timestamped list of system events related to the automation. The log is accessed through the details drawer
- {timestamp}: Run on {Project}
- {timestamp}: Error on {Project}
Inheritance and automation management
Users can only edit an automation at the level it was created at. For example, a user is in the project automation list and views the details of an automation created at the sub-group level. If the user wanted to edit this automation they would have to go to the sub-group automation list and edit it from there. Users may disable or enable automations downstream from their origin, given they have the correct access rights.
Permissions
Permission to create and/or edit an automation is dependent on the automation trigger and the user’s access rights to that trigger. Users who cannot edit an automation cannot enable or disable it.
Automation builder
Automation builder
The tool used to create an automation in the application. The builder consists of five sections, Details, Trigger, Condition, Actions, and Automation Status.
Details section
Consists of one required field, (Name) two optional fields, description, tags and a toggle for the user to set state of the automation to either enabled or disabled. This information helps the user manage their automation once complete.
- Name: The name of the automation for the user and system to reference. This is a required field.
- Description: An option text block for users to add more information to their automation.
- Tags: User-defined variables that allow users to distinguish automations from one another and quickly reference them later in the automation list.
- Scope: The breadth of the applicable automation as defined by the user. A user may scope the automation to an entire group, or sub-group, or a single project. Users may also exempt sub-groups and projects from running the automation.
- Group exemptions: Sub-groups and/or specific projects
- Sub-group exemptions: specific projects
Trigger section
Triggers are what start the processing of an automation. When any of the automation's triggers becomes true the automation will run. This section is required.
- Trigger objects: System objects that have the ability to be automated.
- Trigger events: Events that contain criteria that will enable the automation when they become true. Events are unique to the defined trigger object.
Conditions section
Additional statements that add more granularity to the triggering of the automation. When the trigger events meet these criteria, the automation will run. Users may add multiple conditions and define them as and/or, leading to more flexibility in the automation. Conditions are unique to the defined trigger object. This section is optional.
Actions Section
Actions are the desired result of an automation. These are unique to the defined trigger object and will only be executed if the trigger event criteria and conditions (if applicable) are met. Users may define one or more actions to execute. This section is required.
Automation test section
By default, when creating an automation, the automation test section will return an incomplete message. When the automation has a defined trigger and action the message will change to “untested”. This section only appears when the user clicks on the “Test automation button” and gives a summary of the automation’s validity. If there is an error in the automation the details of that error will be displayed in the appropriate area of the test section.
Saving an automation
Automations can be saved regardless of status. The status of the automation will be visible in the automations list.
Figma file
Current: https://www.figma.com/file/fQghXCqIwO68XZ6FvvoQ7t/Automations?node-id=0%3A1&t=baiqYMzg0cYZZxoE-1
Original: https://www.figma.com/file/AFYCXt5iW9kiz7MmWSwvrD/Workflow-Configuration