Ground 0 of Process Implementation

There are a few things you need to do before you actually create your process in Bizagi. Because Bizagi remembers everything and changing / deleting processes is not the best course of action, it is best if you have a clear idea of what you need:

General information

• Process Name
• Process code (usually a 3 letter descriptor of the process, make it obvious as it will be heavily used in both technical implementation and business referencing)
• Case numbering – usually the format is ProcessCode_NumberSequence
• Process entity name – usually M_ProcessName
• Understanding of data domains pertinent to your process (aids in data model creation)
• Remember the Case Cancel policy

Data Model Governance

• The data domains should be clearly identified. There should be :
  • Operational entities which help the developer hold information about the process. (eg: status, performers on case, flags used in expressions, etc). These are usually process specific.
  • Integration entities – they are used whenever you have an integration point. It might seem easier to just map the values you have in your existing entities but that has proven to be more trouble for large implementations that it is to create a mapping expression.
  • Business data:
    • Process specific business data – this is data used strictly as part of the process you are implementing.
    • Standardized/Reusable data – this is data that has the potential to be reused in more than one process and should be standardized at organization level. (eg: Currency, Gender, Occupation parameter entities, Client Profile, Account master entities, Related entities collection). These entities should be referenced rather than created in the process.
• Entities naming conventions:
  • M_ProcessName – Process entity (Always use a dedicated process entity)
  • ProcessCode_M_OName – Process specific entity – operational data
  • ProcessCode_M_Name – Process specific business data entity
  • INT_AppShortCode_Name – Integration entities. App short code refers to a code given to the application we are integrating with. (for a salesforce integration we would have INT_SF_Account, INT_SF_Transactions, etc)
  • PRS_Name – persona entities
  • ProcessCode_P_Name – process specific parameter entities
  • P_Name – general parameter entities
• Attributes naming conventions, prefixes for different types of attributes makes it easier to know what values are needed. Example:
  • s – string
  • i – integer
  • c – currency
  • u – file, image
  • f – float
  • x – collection
  • km – master entity reference
  • kp – parameter entity reference
  • kpr – persona entity reference
  • ks – system entities (eg: users)

Rule Standardization

• Naming conventions for rules. We recommend processcode_prefix_name when creating process rules. Prefixes we generally use are:
  • fil – filtering rules
  • val – validation rules
  • set – processing rules
  • vis – visibility rules
  • cal – advanced processing
• Naming convention for library rule is a good descriptor of what the rule does. The process code is optional if it is not a rule to be used specifically for that process.
• What is the degree of modularity, what functionality should be created as library rules and which is enough to be encapsulated in an expression. What are the guidelines for that?
• Null values policy
  • If using attributes in doing calculations like multiplication, addition, concatenation, division, etc make sure they are not null by storing them in a variable:

    var iSum = <M_Request.kmOutcome.iTotalSum>
    iSum = (iSum == null) ? 0 : iSum;

  • If using object methods make sure the object is not null (eg: before calling the .trim method for a string, make sure the string is not null)
  • When referencing collections make sure the object IS a collection by using CHelper.getValueAsCollection(). This will convert the null into a collection object with 0 elements.

    var xReviewItems = CHelper.getValueAsCollection(<M_Review.xReviewItems[bCompleted = true]>);
    var iItemsSize = xReviewItems.size();
    

Tracing Standardization

• Create a Common Library tracing rule to be used by all expressions. Use a unique identifier to name the trace files (eg: case number)
• Make sure you have clear structure to tracing of your rules like: starting each rule with START ========= and ending it with END ==========.
• Make sure not to log sensitive information like PPI (GDPR) or medical information (HIPPA), etc.
• DO NOT log information in files that have no clear identifiers, it will be much harder to identify issues.
• Connector traces should follow the same logic of using the same unique identifier.

Form Framework – work portal forms

• The forms should have a cohesive appearance and structure. Usually you have a general information area at the top of the form identifying the case, a working tab where the editable sections of the form are, an audit tab to show what happened on the case and an additional information tab. (may have a related cases tab, attachments tab, etc)
• Other considerations
  • Collection header and body alignments and style
  • Formatting of currency fields
  • Label to field ratio
  • Naming Conventions of forms