Where to manage Parameter entities

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Process wizard > Data Modeling > Entity types >

Where to manage Parameter entities

Overview

Parameter entities can be classified into two sub-types: Manageable in the production environment, or Manageable in the development environment.

It is really important that you consider this classification, so that you best design your Parameter entities in terms of system maintainability.

For a basic explanation about Parameter entities, refer to Entity types.

 

The criteria to choose one type or the other, depends on how you expect their values to be defined and managed:

They can be defined and managed dynamically by a business administrator in the production environment according to the business needs, or they can be defined and managed during design time (in the development environment).

 

 

1. Manageable in the production environment

For an entity to be manageable in the production environment, it means that the entity’s values will be entered and edited by a business administrator, separately on that particular production environment.

Such values will not be promoted from a development environment to a production environment, save only for the very first time when an initial deployment is carried out.

Administration of values in a production environment is easily done through options in the Work portal, as described at Include records in Parameter Entities through the Work Portal.

 

Example

Assume we have a Parameter Entity called Documents Requested.

This entity contains the list of all documents that are requested to every customer when opening a bank account.

Required documents can be certainly added, modified or disabled (according to regulations or specific business needs).

Consequently, the list can vary significantly over time, at unpredicted moments and unknown time intervals.

Therefore this entity should be manageable directly in the production environment, since this will allow the flexibility to edit values anytime through Bizagi Work portal options.

 

Quick facts

Make sure you acknowledge these facts when deciding over where to manage Parameter entities:

 

Deployment: Initial synchronization, then handled separately in each environment.

Values of entities manageable in production will be available for administration in each environment (development, test and production).

These values can be taken from the development environment into the production environment (synchronized), but only for an initial deployment (the very first deployment).

After the first deployment, values in each environment will not be synchronized and will need to be handled in an entirely independent manner.

 

Switching its definition.

You may convert an entity manageable in production so that it is set as manageable in development only if: That entity has no forms associated (not being currently used), it is not in use by Bizagi Data Replication, it has no collections, and if it has not been deployed yet to a production environment.

In addition to the above, you will need to ensure that it is compatible for management in a development environment (e.g, if it does not have in turn a relationship of any type with another Parameter entity which is manageable in production).

For more information about compatibility definitions in this aspect, refer to the Where to manage the Parameter entity section below.

 

 

2. Manageable in the development environment

Parameter entities that are manageable in development environment will not be displayed for edition in the production environment.

This means that end users will still be able to work with their data in a case, but that data will not be available for dynamic changes without a deployment.

 

Entities which are manageable in the development environment are very useful to define a finite list of possible values that affect the process routing.

These can be also used to hold a list of predefined values that you know they will not change over time, such as Gender.

The main advantages when using this type or Parameter entity are: that you avoid administration overhead in the production environment. specially when you identify there will be no need to provide the option to administer such values (nor add, modify or disable), and that you have more control over the process workflow's business parameter values.

Administration of values in a development environment is easily done through options in Bizagi Studio, as described at Include records in Parameter Entities through Bizagi Studio.

 

Example

Assume we have a Parameter Entity called Request status.

This entity contains the list of possible states of a request: approved and rejected.

Assume that according to the state set for the request, as evaluated by an approver, the process workflow takes a different routing that fires up a different set of tasks: if the request is approved then the process moves on, but if it is rejected then it is finished.

Given that this is a finite list of values which directly affect the process workflow, this entity should be managed from the development environment.

You will have more control and further possibilities over what the workflow does according to a specific value, and there will also be no point in having a business administrator be presented with the list of these values.

In the event that a new value is needed (for instance, assume a "needs revision" status), then it is usually expected that you define this new status in the development environment, alongside with any modifications to your process workflow so that it acts accordingly (i.e enables an end user to review the request when marked under this new possibility).

 

Quick facts

Make sure you acknowledge these facts when deciding over where to manage Parameter entities:

 

Deployment: Development values always overwrite those at production.

Values of entities manageable in development will always be taken to the production environment within a deployment; and these will overwrite any existing records (or new ones will be insert as well if applicable).

 

Switching its definition.

You may convert an entity manageable in development so that it is set as manageable in production at any time, though you will need to ensure that it is compatible for management in a production environment (e.g, if it does not have in turn a collection of values from a Parameter entity manageable in development).

For more information about compatibility definitions in this aspect, refer to the Deciding where to manage the Parameter entity section below.

 

 

Configuration and default behavior

By default, Parameter entities start off as Manageable in development environment (if you do not carry out any action when creating entities).

As a best practice, you should define this property whenever a new Parameter entity is created and review it before deploying to production.

 

To configure this, notice the entity creation wizard for Parameter entities only, shows the Manage values in Production environment checkbox located at the bottom of the window.

By default, the checkbox is not ticked so it is recommended to review and think over if your need to allow this entity to be manageable in the production environment:

 

where to manage parameter3

 

For an existing Parameter entity (if you skipped the initial configuration or to modify it), this property can be reviewed through the Expert View.

Once there, select the Entities module, right-click the given entity and choose the Advanced Properties option.

Under the Instances tab, you can locate checkbox to mark or leave unmarked correspondingly.

 

where to manage parameter4

 

In Bizagi Studio, notice that Parameter entities will have an additional mark that makes them look slightly different according to this property's values, as shown below:

 

Where to manage parameter2

 

 

Deciding where to manage a Parameter entity

If you have trouble determining whether an entity should be manageable in the production or development environment, consider the following:

 

Where to manage parameter1

 

Scenario

Should be Manageable in production

Should be Manageable in development

The entity's values will be used in any kind of rule like an expression, or assignment rule, or in a form having actions and validations.

 

X

The entity's values will be used to define how the process workflow reacts (logic behind the routing).

 

X

The entity will need constant administration, because its values are likely to be changing and updated often.

X

 

The entity will need a relationship with the WFUser (references this special System entity which is handled in production).

X

 

The entity will need a relationship with other System entities such as Area, Role, Location, Skill (these System entities all have their values defined in the development environment).

 

X

The entity will need a collection (1-n relationship) of another Parameter entity which is manageable in the development environment.

 

X

The entity will need a relation (of any type) with another Parameter entity which is manageable in the production environment.

X

 

 

For a better illustration on how you may create compliant relationships for each of the 4 possible combinations when having the two sub-types of Parameter entities, refer to the image below:

where to manage parameter5

note_pin

Recall that on a general basis, a Parameter entity should be marked to be managed in Production if it is meant to have new values added dynamically in the Production environment on a frequent basis (or if you foresee this).

But while in doubt, it is best to leave it as manageable in the development environment.

Nonetheless, it is recommended to go through the definition of all Parameter entities together with the Process owner (the customer from the business department of your implementation) to gain a better foresight on this, and end up deciding accurately.