Overview
To avoid users overwriting each other's changes in Business Rules when working collaboratively, Bizagi provides a Check-in / Check-out functionality.
As soon as an Expression (scripting or Boolean) is opened to perform changes, it is automatically locked for other users.
Thus, the first user to open an Expression is able to change it. If someone else opens the same Expression while it is checked-out, then a message will display informing who has it locked, and it will display as read-only, as shown below.
When in read-only mode, team members will be able to see the rule, but they won't be able to perform any changes since all the controls will be disabled and access to the expressions editor will not be enabled.
Check-in or enabling for edition
If the user that has the Expression locked closes it, it is automatically checked-in.
When an Expression has been checked-in, it will be available for the rest of the users to edit. There is not option to check-in an expression, closing it is the only way to make it available again.
Force check-in
As a last resort option, in case there is the urgent need to modify an Expression that a user has checked-out, the Force check-in feature is available.
The check-in / check-out functionality of Expressions is very important to prevent users from overwriting each other's work and to allow them to collaborate on a project efficiently. Nonetheless, it has an important caveat that needs to be addressed: there are innumerable situations in which an Expression could be checked-out by a user who for some reason will take a long time to resume working. For example, a user checked-out an Expression and locked his workstation, he then headed out for his vacation. Thus, the rest of the team will not be able to make changes to that Expression until he returns and checks it in. That is why the Force check-in feature is introduced. This feature will allow team members to force the check-in of an expression that a user had locked, and check-out the Expression in their own session. All changes that had not been saved will be lost.
The user that had the Expression locked won't enter read-only mode, nonetheless, if he tries to perform any change a message will display informing him that another team member has checked-out the Expression and that it is not possible to perform changes at that time.
Example
Carolina Middleton and Jonathan Edelstein are working together on a collaborative project. Carolina accessed a rule and thus it is blocked for Jonathan to edit it.
Jonathan noticed that Carolina has not checked the rule in for a long period of time, so he contacted her in order to find out what is going on. Carolina informed him that she is sick and will not return to work for a week, so she said there is no problem with him forcing the check-in of the rule in order to resume working.
In order to force the check-in of the rule to his session, Jonathan clicks Carolina's name on the message displayed on the screen. Consequently, the following warning is displayed.
Since the users have already contacted each other and agreed on Jonathan forcing the check-in of the rule, he will proceed with the process. Once he clicks the Unlock expression option, all changes made (but not saved) by Carolina will be lost, and Jonathan's application will exit the read-only mode allowing him to edit the rule, that is, after confirming once again that he wishes to do so. Furthermore, the rule is now checked-in by Jonathan, so it will be blocked for Carolina or any other user to edit it.
After clicking OK Jonathan will have the rule unlocked and available for edition.
Carolina returned to work a week later and immediately tried to perform changes to the rule, which was now locked by Jonathan. Even though she did not entered the read-only mode, she will not be able to perform changes and Bizagi will notify her of that, as shown below.
This way both of them can rest assured that working collaboratively in Bizagi will have no overwriting risks since the check-in / check-out functionality prevent them from doing so.
Last Updated 1/6/2022 4:21:56 PM