Bizagi Modeler cloud services consists of additional sets of services and added features to host your projects in the cloud and enable teamwork, leveraging on Efficiency, Collaboration and Governance.
Bizagi Modeler plans brings various benefits, including:
•Global access to all your models.
•Staying productive from any device.
•Teamwork and business collaboration.
•Delivering fast results.
•Posting comments and sharing ideas.
•Reducing the learning curve.
•Inclusion of attachments.
There are different Bizagi Modeler plans that adjust to your needs: Personal, Professional, Workgroup or Enterprise.
Some features are only available for a specific plan, and that is the case for Extended attributes validations, which will be described in detail in this section.
For more information on Bizagi Modeler plans, refer to this section.
Bizagi allows model editors to document their processes and its elements. The information added on Bizagi Modeler to processes and elements will be considered and properly organized when exporting documentation to multiple formats.
Shapes used in models have basic documentation attributes that can be filled to explain project specifics and for future reviews. This attributes can be accessed and documented by right-clicking on any shape, choosing the properties option and checking the Basic section on the pane displayed on the right.
It is common for organizations to set a documentation standard, stating the attributes and the respective type that should be given to them, to uniformly maintain projects over time and facilitate new team members to explore and understand projects with a less steep learning curve.
Bizagi acknowledges that fact and allows model editors to create their own attributes. Those are known as Extended attributes, follow the link for detailed information about them.
Managing extended attributes can get complicated since they are shared through all the elements of the same type that it was created on and also because they can be shared by the editor to different element types. This is specifically crucial in Enterprise environments. Having that in mind, there are some important behaviors that should be thoroughly explained: What happens when an extended attribute is going to be deleted? What happens when a shared attribute is going to be removed from the shared elements type list? What is the behavior of this cases when dealing with table type extended attributes? What happens when an attribute is going to be edited?
In this part of the section, the different situations previously described are going to be addressed.
Imagine an Enterprise environment where dozens of team members collaborate in designing and developing complex business processes. The diagrams can become an entangled and difficult to follow mess very easily. That is why the team decided to document with their own attributes every single element of their processes. After lots of time invested in documentation, a team member wants to perform a change on an attribute, it can be a deletion, edition, un-sharing, between other actions. To prevent the user from making irreversible changes (like deleting an attribute from all elements) Bizagi performs validations and informs the editor when any operation can be harmful.
When an extended attribute was already documented in one of the shapes of the element type it was added to, and then the editor tries to remove it, a pop-up window will be displayed, informing the user of the situation and preventing them from the deleting the attribute.
In the pop-up window, the editor will have the option to review the dependencies of the attribute, that is, the list of diagrams and its elements where the attribute has been used. This way the editor can check why they cannot do the deletion and are provided with information to then go ahead and review it.
When an extended attribute is being edited, the option to select the attribute's type will be disabled. This is to prevent a user from changing an attribute type when one shape had already been documented with the original type. The Name, Description or specific details of the attribute when it was defined, for some specific types (like Single Selection Option (radio)) will be enabled for editing.
If an extended attributed was shared from one element type to another one, consequently it has been used for documentation in that second type of shape. When an editor enters the sharing options of the attribute and intentionally (or mistakenly) tries to remove an element type from the sharing list, a message indicating of the situation will pop-up, showing the dependencies of the attribute.
If the user chooses to cancel the operation, the attribute will remain untouched and its documentation will continue to be available.
On the other hand, if the user continues with the operation by saving or hitting Ok, a confirmation window will emerge warning the user once more to make sure that he really wishes to do so.
If the user continues with the operation, the extended attribute of the element type will no longer be available for any of the shapes, and all of the documentation that had previously been added will be lost.
Notice that in the Extended attributes of a Script task, the "Importance of task" attribute is no longer available.
When an extended attribute of table type was originally created, the types and details of each one of its columns were defined too. There might be cases on which an editor may need to modify a table attribute. In such situations, when entering to edit the table attribute, the user will not be able to modify any column's type since it will be disabled, the other details (namely Name and Description) can be modified normally. The reason for this behavior is to prevent users from changing a column type when there might already be documentation made for some other shape with that original column type. This mimics the case of editing an extended attribute.
This case presents the same similarities that editing an attribute and a column exhibit. There might be situations in which an editor no longer requires the presence of a column on a table attribute. When he/she enters the edit options of the attribute and locates a column to delete it, a pop-up window will be displayed, informing the user that the column has documented information and providing a dependencies view so that he/she can review exactly in what shapes of the project it is being used.
The user can cancel the operation, in which case the column will not be deleted from the table attribute and the previously documented information will be safely kept.
Alternatively, after reviewing the situation, the user might still want to continue with the deletion. In this scenario, a confirmation window will pop-up (when hitting No in the review dependencies prompt) and the user will have to confirm once again his desire to eliminate the column. If the operation is continued, the column will be deleted and all previously documented information will be lost.
For the validations to take effect and the confirmations to be shown before making any change that might be harmful, Bizagi should have successfully indexed the new information in the advanced search option. This means that after making any changes, like adding an extended attribute, to experiment the behaviors as described in this section the user should wait a couple of minutes. A good way to know if the changes have already been indexed, is to navigate the model on the cloud and check if the changes are available there, in which case Bizagi has already indexed the information.