Flowcharts - In Detail
Go with the flow - Example of Flowchart in a Workflow scenario
Embedded Files
How do I design and deploy the Workflow using a Flowchart?
How do I design and deploy the Workflow using a Flowchart?
Superuser (or any role with permissions to configure workflows) defines the Workflow type with relevant Statuses, relevant Fields and Flowchart
Test the workflow as a Tester user - You can toggle certain users from the Edit User form as Tester User
Give required permissions to User roles
Publish to Live - Now, the workflow is available for applicable User roles when they log into their accounts on Desktop and/or Mobile application
For e.g., User logs in on Mobile app > User hits Add Workflow > Selects Member/Group (if applicable) and sets Due Date > Starts the workflow > Workflow executes as configured in the flowchart
☞ Test vs Published modes of flowchart is available ONLY in Workflow context; All other contexts (Reports, Dashboard and Computed Field) have only one flowchart state/mode namely Published; So, if you make a change in a Dashboard flowchart and sync, it gets directly published to the affected users.
Define a Workflow Type
Define a Workflow Type
Assume that we are creating an independent/unaffiliated workflow type. Basically, it means that this workflow doesn't use (or need) any Member data to get executed. For example, a simple survey of your users. Please refer to the Configuration Manual page if you are a bit fuzzy about the concepts.
As shown below, this Workflow is named My Survey, belongs to a Project called My Survey Project, Affiliation = None, has 2 Statuses namely Open and Closed and has some Customfields defined which we plan to collect. Towards the bottom-center of the screen you will see a Go to Flowchart button. This is where the actual form is designed which is eventually deployed to the user.
☞ Context is important when designing a Workflow. If it is a workflow which is unaffiliated, you have access to the current User's data w.r.t Members, Groups, Workflows and some User attributes. If it is a workflow which is affiliated to a Member type, then User must select a specific Member for whom this Workflow will be executed. Auto-magically, this workflow has access to data of that Member and also becomes a transaction in that Member's history. Same is the case with Group type affiliated workflow.
☞ Workflow is added/executed from the user's context. So, a user who has permissions to execute a certain workflow can execute it ONLY for the Members and Groups (in case of affiliated workflows) assigned to him/her via the Location. Please refer to the Configuration Manual page if you are a bit fuzzy about how User and Location are connected.
Go to Flowchart
Go to Flowchart
By default, you will land in the Test section of the Flowchart. This is where you want to make changes and test with marked Tester users (toggle in Add/Edit User form) until you are ready to deploy to a wider set of production users.
When you are ready to publish to production, click on Publish to Live button. The Live section is not editable and is a view only page. On the Test section, you will see a left hand side panel of Pieces which are programming pieces available for designing the Workflow.
First piece of a workflow is always a Start piece, which is added by default to every flowchart. Application looks for pieces attached under this Start piece to execute the workflow in the User's mobile or desktop application. Any piece detached from the pieces connected under Start pieces are ignored.
Given below is an example of an Unaffiliated workflow's flowchart. This is continuing from the Go to Flowchart in image above. Explained are various sections of the Flowchart design page.
Is there a method to this piece-ful madness?
Is there a method to this piece-ful madness?
Like mentioned before, workflows always start with the Start piece. Once you start the execution of the workflow on the Desktop or Mobile application, it always starts with first defined non-terminal Status (by the visible order) and the Due date set to TODAY + Due in Days defined for the first defined Status. In the example above, there is only one non-terminal status which is called Open and it uses that as the starting status of the Workflow for the user.
Workflows must be closed with an End piece and one of the Closed statuses. So, in toto, Workflow flowcharts follow the structure:
Start piece
Step 1 piece/s
Step 2 piece/s
Step 3 piece/s
End piece with CLOSED status and MESSAGE
Show me how it looks when you build a flowchart
Show me how it looks when you build a flowchart
Its a simple search, pick and fit a piece as shown in the video below.
Tell me what did I do - Track changes
Tell me what did I do - Track changes
Release 4.11.10 onwards, we have added a Track Changes feature which allows Configurator to compare current Test version of flowchart with the Published version. It shows the Added, Updated, Deleted and Moved pieces. Some notes before using the same:
You must Publish/Sync the Test version of the flowchart at least once before using this feature; If you already have deployed flowcharts, this is required before you can start using the same.
Track changes helps Configurator to ensure they dont send out temporary changes inadvertently. It is a good practice to run this feature before doing a final publish
Nested pieces are shown separately as a change. Say, you have a Grouped question with Is Required = <TRUE> and Default value set to a <VARIABLE>; If you delete this piece, it will show up as 3 deletions namely Grouped question, <TRUE> piece and <VARIABLE> piece.
Google Sites
Report abuse