Details
-
Story
-
Status: Closed
-
Minor
-
Resolution: Discarded
-
None
-
None
Description
As an App Admin, I want to define additional transitions (actions) that will be available in each of my App's workflow steps (secondary actions), so that end-users can correctly choose and transition workflow instances of applications that have multiple different paths in the same workflow process.
Design Deliverables
Context
In our MVP, we decided to limit the Workflow Powered Apps to build only linear workflow process. However, we know that this is not enough to represent most of the real world use case of customers. Most workflow processes shall need non-linear workflows that have multiple paths (transition) options in each state of the workflow.
With that being said, this Story aims to allow users to define multiple transition actions in each Workflow Step. This way, users can not only have two transitions (back and forward), but the flexibility of choosing which paths should be available to transition in each step.
In this Story's scope, users should be able to:
- Define two or more Transition Actions for one same Step in the Workflow Powered App Builder;
- Select for which step each additional Transition Action should transit to.
- In an ongoing App Workflow Instance, see and select which of the available transitions that instance should go through.
- Though the App's Table View;
- Through the Instance Details View.
Acceptance Criteria
1- Define more than two transition action for the same step
Given that a user is configuring the Actions of a Step of a Workflow Powered App and the Step isn't the Start-step,
when the user clicks in the "Add New Action" button,
then the system should add a new Secondary Action option for the Step, allowing the user to define the Action Name and the Step to transition to.
2- Execute with more than two transition action for the same step
Given that an App Admin created an Workflow Powered App that has multiple secondary actions for one same Step,
when an assignee of a instance that is in one of those steps that has multiple secondary actions enters the details screen of the App's instance,
then the assignee should be able to see all available Transition Actions and choose which one the instance must follow through next.
3- Default action should be the primary one
Given that an App Admin created an Workflow Powered App that has multiple secondary actions for one same Step,
when an assignee of a instance that is in one of those steps that has multiple secondary actions enters the details screen of the App's instance,
then the user should be able to identify which transition is the primary transition action of the step.
4- See all transitions in the workflow process diagram
Given that a user is configured all the Actions of all Steps of a Workflow Powered App,
when the user looks at the stage of the builder (the workflow process diagram),
then the user should be able to understand what are the transition actions going in and/or out of each step.
5- See what are the primary transitions of each step
Given that a user is configured all the Actions of all Steps of a Workflow Powered App,
when the user looks at the stage of the builder (the workflow process diagram),
then the user should be able to understand what are the primary transition actions set for each step.
Definition of Done (DoD):
- All Acceptance Criteria were passed;
- Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
- Code with peer review completed;
- Validated by QA, Product Designer and/or PM;
- No critical bug related to Story scope (ex.: similar of FP4, FP5);
- Make sure that all system documentation were updated (if necessary)
Make sure that it has the extensions points needed to allow GS and customers to customize the feature (If applicable)
