Details
-
Story
-
Status: Closed
-
Minor
-
Resolution: Discarded
-
None
-
None
Description
As an App Admin, I want to manage my Workflow App's Actions and Notifications though the Workflow Builder Portlet.
Context
One of the main values provided by the App Builder is the automation of business operations. Once the creation of Standard Apps aren't well driven for this use case, we decided that we should offer a separate and special experience for users that wants to create Apps to automate a business process, in way that we can leverage on the Apps tools that we have (Data Objects, Form and Table Views) and enhance it with Workflow capabilities.
The result is what we are calling "Workflow Powered Apps". A special type of App with an intuitive interface that can create Apps integrated to a Workflow, making any data gathered from Form Views flow through different steps of a process to be reviewed or even complemented with more information.
In the scope of this Story, we want to allow the user to use the "Workflow Builder Portlet" to define additional configurations of the "App's Workflow" that won't be available yet in the "Workflow App Builder" UX.
In this Story's scope, users should be able to:
- See the Workflow created for this Workflow Apps in the Workflow Builder Portlet;
- Define additional configurations on the Workflow App's nodes through Workflow Builder Portlet:
- Define Notifications;
- Define Actions;
- Define Timers;
- Define Description of Nodes.
Acceptance Criteria
Given that a user successfully configured all the required configs of the Workflow App Creation,
when the user deploys the Workflow App,
then the system should create a new Workflow Process according to the Users configurations and attach it to the new App created.
- Workflow Process created through the App Builder creation experience should appear in the Workflow Builder portlet with the following constraints:
- Cannot be deleted;
- Cannot be unpublished;
- Cannot have it's permissions modified;
- Cannot have new nodes or transition added;
- Cannot modify which transitions are Default;
- Cannot make changes on the Transition/Nodes' Names, Type and/or Assignment;
- Cannot modify Source Code directly;
- User should only be able to:
- View (read-only);
- Define Notification Config of Nodes;
- Define Action Config of Nodes;
- Define Timer Config of Nodes;
- Define Description of Nodes.
Definition of Done (DoD):
- All Acceptance Criteria were passed;
- Make sure that the expected automated tests were created (unit / integration / functional) and passed successfully;
- Verify if the test labels were added;
- 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)