5 crucial tips for your first Bizagi project

For many companies Bizagi is a cost-effective way to digitize their processes and to connect existing systems. That is why you could call Bizagi a rapid development tool, with which you can quickly setup completely working prototypes. But keep guard for a too iteratively and explorative approach.

The danger exists that developers want to go too quickly, in the spirit of prototyping. While other programmes have a controlled refactoring on the coding level, Bizagi Studio will require a lot of clicks to get the same result. With certain components, like the names of entities, it is not even possible to edit. For that reason we will give you five crucial tips for your first Bizagi project, based on Bizagi documentation and our own insights.

1. Use prefixes for entities and attributes

When you create entities Bizagi equates the name of the entity with the display name. We recommend to start the name of each master entity with “M_”, each parametric entity with “P_”, and each stakeholder entity with “S_”. That way you can easily find the tables on database level between the tables of Bizagi itself. When you start a new project we also recommend to first create your master entity using the expert view. If you follow the standard flow, Bizagi will create a master entity with the process name and the prefix “M_” will be missing from the start. Furthermore, we would like to recommend using singular words for all entities.

If a master entity or parametric entity is only valid for one process, you can add a second prefix that will refer to that process. That way you can ascertain if the table can be reused in upcoming processes. Do not just name a table “P_Procedure” if it is only one kind of procedure, or set it up in a more general way so it can be reused later.

When creating attributes we recommend using a prefix that matches with the type of the attribute. It makes sorting really handy and gives clarity in expressions:

• “b” for boolean (for example, bApproved)

• “c” for money values, with the monetary unit as suffix (for example, cPriceEUR)

• “d” for dates, that way you can leave out the word “date” (for example, dApproved)

• “i” for whole numbers

• “s” for strings

• “u” for files

• “f” for decimal numbers

• “km” for a linked master entity (for example, kmCustomer)

• “kp” for a linked parametric entity (for example, kpStatus)

• “x” for collections, here the plural of the linked master entity (for example, xApprovals, xItems)

2. Make the English language leading and keep translations at the source

Even if the target audience of your application does not speak English, we do recommend to write all names and display names in English. Set up a table with all the translations you will need. That way entering attributes into the data model can be done quickly and you can be sure every attribute has been translated. Do this upfront, during the analysis. Apart from UI controls that are not linked to your data model (for example, an extra label, a button, a group framework…), translation may never be used in a form, but always on the “Edit attributes” screen of the data model. Also know that you can quickly click through from your form to your data model.

3. Always give expressions a name, even if you are in a hurry

You can set up expressions in your form, for example to set the visibility, adjustability, or mandatory filling of an element, reasonably quickly. We do recommend that you check “reusable,” so you can choose a name yourself. Because you have to admit that “boolexp0123” does not mean a lot. Choose a name that emphasizes the “how,” rather than the “what.” For example, “ifUserIsCaseCreator” is a far more suitable name than “setEditabilityOfFieldX.”

4. Set a business key for parametric entities by default

By default we add an attribute with the name “sCode” and the display name “Code” to each parametric entity, after which we select that attribute as business key, using the advanced properties of the entity. This field is particularly suitable for containing, for example, 3-letter codes of countries or monetary units, so you can quickly reference to it in an expression. Never refer to another field in the code. And when you permit edits via the work portal, set the Code field to read-only using a custom edit form (which you can also set in the advanced properties).

5. Think of a tracing syntax before you start your project and implement this rigorously within every expression

CHelper.trace is a method used during development to gain insight into expressions that have a malfunction. Within Bizagi you are free to choose whichever file you want to write this to, and what the trace will contain. This way you can dynamically generate a logfile for each process, using Me.Case.ProcessDefinition.Name. Furthermore, you best record the logged in user and case number in your log by default, using Me.Case.WorkingCredential.FullName and Me.Task.DisplayName. Always define a variable with the name of the current expression. Also know that you can force new lines using Environment.NewLine to get a comprehensive and readable log. You can also choose to write the case number into the file name. That way you will keep all traces for the same case together. Something to keep in mind when you start.