In our recent article, we explored the basic configuration of Request for Changes in our Bureaucrat system.
Today, we'll look at some of the advanced configuration options. The general idea is to divide the overall complex RFC process into smaller, simplier parts and to add automation for more convenient request processing.
Let's review the On Approve stage of our RFC workflow. It would be convenient to separate approvement process as a new request. Thus, we create a new Approve request type with a simple workflow: Approve or Reject. And we set up RFC actions to automatically create the Approve subrequest any time request gets to the On Approve stage.
A new Approve type of request looks like this:
With a simple flow:
Now we can open Request for Changes and create automated actions.
Click Actions on the request type form.
Click Create to create a new action.
We enter the action's Name.
Select event - Stage changed.
The type of action is Subrequest.
Below, we select the type of subrequest to be created - Approve.
Thus, we automatically create the Approve subrequest when RFC moves on the route from Draft to On Approve stages.
We also create the same action but on the route from Returned to On Approve.
We want to create another 2 actions to mark request with the appropriate tag after approval. To apply a tag, we can use the Server Action action type. We create the first action for the On Approve -> Assessment of Requirements route.
In our case, this action was pre-configured to execute a certain Python code.
We can setup custom actions in the Settings ->Technical -> Actions -> Server Actions.
Now we create the same action, but for the On Approve -> Returned route.
For more information on auto-actions, see the Documentation.
To complete the approval process, we can also make triggers to automatically move approved requests to the assessment stage or return them in case of rejection.
To create a trigger, we need to open the required route and click Triggers on the form.
We open the On Approve -> Assessment of Requirements route and create a trigger. It moves request when its subrequest is moved and trigger conditions are fulfilled.
We also use custom condition for this trigger. It based on related conditions and checks if the subrequest of the current request is closed (positively) and has the Used tag simultaneously.
Custom conditions can be configured from the Rules -> Generic Conditions menu. More information on conditions - in the Documentation.
We create the second trigger on the On approve -> Returned route. this trigger automatically moves requests by the current route if subrequest is negatively closed (rejected) and has the Used tag.
For more information on automated routes, see the Documentation.
Now we have configured Request for Changes with basic workflow and partial automation. For further improvement we can set up integration with the Project to be able to automatically create tasks, for example, on the Progress stage, and to have the ability to automatically move requests when all tasks are done.
More information on how to do it can be read in this Guide.
Check out more advanced RFC configuration in the following articles.
Follow our blog for the latest news.