Change management for Bizagi Cloud

<< Click to Display Table of Contents >>

Navigation:  » No topics above this level«

Change management for Bizagi Cloud

Objective

This document describes the procedure to follow whenever you, as a Customer of Bizagi Cloud, need to request a change affecting your Bizagi Cloud subscription service.

Such Change management presented here, establishes an orderly and effective procedure for the submission, coordination, and revision/tracking to release a change into your subscription.

 

Concepts and terms

Consider the following terms as used throughout this document:

1.Bizagi: Refers to the company as a whole (Bizagi Group Ltd or one of its subsidiaries); which offers the cloud service and products, and similarly involves personnel to admin and maintain those cloud services and products.

2.Bizagi Cloud: The subscription-based cloud service as offered by Bizagi.

This service entitles Customers to make use of Bizagi environments, as agreed in the subscription's contract and as detailed in the subscription's order form.

3.Bizagi environment: A Bizagi environment is a set of resources which are provisioned in order to support a given stage of the life cycle of Customer applications.

This means that Bizagi environments are: Development environment, Testing environment, Staging/Build environment, and Production environment.

All environments except the Development environment, follow a similar architecture and fall under a same category referred to as Runtime environments, due to their use of Bizagi Engine.  

4.Bizagi Engine: The specific product that executes the Customer applications, and renders them available for user access through a web-based Bizagi Work portal.

5.Bizagi Work portal: A web application accessed by users (via HTTPS) either from desktops, tablets or smartphones, in order to allow working on the Customer applications.

Each of the different Bizagi environments, has its separate Bizagi Work portal though it supports the same features:

For the Production environment, users accessing its Bizagi Work portal are end users working on daily tasks of the Customer applications put into live operation.

For the Testing environment or the Staging/Build environment, users accessing its Bizagi Work portal are testers that carry out user-acceptance tests.

For the Development environment, users accessing its Bizagi Work portal are developers who perform unit tests or quick prototyping on what they are currently modeling.

6.Customer applications: The business-driven applications which are modeled and implemented by the Customer itself, and which include any number of corporate processes in it.

Example of corporate processes include primary/core processes such as: credit request for companies in the financial sector, policy underwriting process for companies in the insurance sector; or includes as well support processes such as: the recruitment process of a Human Resources area, the vacation leave request process, purchase request process, among others.

7.Bizagi Studio: The specific product that allows developers to model and implement Customer applications in the Development environment.

8.Bizagi project: Customer applications are modeled and implemented inside of a Bizagi project.

A Bizagi project features:

Its own separate repository (i.e, a separate database).

Its own Bizagi Work portal, with its own mechanism of authentication for user access, its own set of authorized users, and its own separate URL.

Furthermore, each Bizagi project already provides the different Bizagi environments needed, so that there is a separate repository (database) and separate Bizagi Work portal for each of the environments (Development environment, Testing environment, Staging/Build environment, and Production environment) --per Bizagi project.

 

Change management scope

Change management includes requesting to Bizagi certain types of changes regarding the use and access to Bizagi Cloud.

 

Types of changes are:

1.Creating one or more Bizagi projects.

Its procedure is coded as CM01, and its detail is described at CM01 - Creating new Bizagi project.

 

2.Creating one or more new Bizagi environments (for a given Bizagi project).

Its procedure is coded as CM02, and its detail is described at CM02 - Creating new Bizagi environment.

 

3.Resetting a password for a given developer (accessing the Development environment).

Its procedure is coded as CM03, and its detail is described at CM03 - Resetting developer password.

 

4.Granting new access to a developer (to one or more Bizagi projects in the Development environment).

Its procedure is coded as CM04, and its detail is described at CM04 - Granting developer access.

 

5.Revoking access to a developer (to one or more Bizagi projects in the Development environment).

Its procedure is coded as CM05, and its detail is described at CM05 - Revoking developer access.

 

note_pin

Consider the following:

 

1. If there should be the need to switch the access for a developer from one Bizagi project to another, consider requesting both CM04 and CM05 (grant access to the new Bizagi project while also revoking access to the old one).

 

2. The above types of changes are not a comprehensive list of all the actions a Customer subscribed to Bizagi Cloud may perform.

However, other actions not mentioned above are provided throughout self-service options at the Management portal under http://www.bizagi.com.

 

CM01 - Creating new Bizagi project

Creating a new Bizagi project applies whenever you as a Customer, want to include a new association to your business model.

Therefore and in order to do so, fill out the following format (table) and submit it to cloud@bizagi.com.

 

CM01 - CREATING NEW BIZAGI PROJECT

SUBMITTER


CONTACT E-MAIL


NAME OF THE BIZAGI PROJECT(S)


PLANNED FOR


GRANTED DEVELOPER ACCOUNT(S)


 

Consider that:

SUBMITTER: Should specify the name of the contact who submits the request.

CONTACT E-MAIL: Should specify the e-mail of the contact who submits the request, and who will be notified once the change is applied.

NAME OF THE BIZAGI PROJECT (S): Should have a list of the names to assign to one or more new Bizagi projects.

The name will be automatically taken to build those URLs related to the new Bizagi project(s).

PLANNED FOR: (Optional) Should specify a date (with UTC time zone specification), for which you want to plan/schedule the new Bizagi project(s) to be available.

Notice that such date is not automatically guaranteed, mainly because requests still need to undergo revision and approval.

You may choose to skip this information, in which case it will be assumed an ASAP approach, and Bizagi will start to work on provisioning the new Bizagi project(s) right away.

GRANTED DEVELOPER ACCOUNT (S): Should specify the list of developers (first name, last name) who will be granted to access each of the new Bizagi project(s).

If you are requesting more than one new Bizagi project, ensure you clarify which developers need to be granted access to which Bizagi projects.

 

note_pin

Creating the new environment will take 1 to 2 days upon reception of the submitted form and given that the request is approved.

Once it is created, you will be notified back via e-mail.

 

CM02 - Creating new Bizagi environment

Creating a new Bizagi environment applies whenever you want to execute Customer applications in an environment different from the Development environment.

Therefore and in order to do so, fill out the following format (table) and submit it to cloud@bizagi.com.

 

CM02 - CREATING NEW BIZAGI ENVIRONMENT

SUBMITTER


CONTACT E-MAIL


BIZAGI PROJECT(S)


NEW ENVIRONMENT(S)


PLANNED FOR


SPECIAL ENTITIES' ATTRIBUTES TO OVERWRITE


 

Consider that:

SUBMITTER: Should specify the name of the contact who submits the request.

CONTACT E-MAIL: Should specify the e-mail of the contact who submits the request, and who will be notified once the change is applied.

BIZAGI PROJECT (S): Should specify the name of the Bizagi project(s) to which you want to create new Bizagi environments.

Note that you may specify more than one Bizagi project, though recall that such request is subject for approval (provided that you are not exceeding the amount of Bizagi projects agreed upon in the subscription's contract or purchase order).

NEW ENVIRONMENT (S): Should specify the name of one or more Bizagi environment(s) you want (for which Bizagi projects) from these options: Testing, Staging/Build, or Production.

Keep in mind that only for a Staging/Build environment, a new environment is created upon an existing data backup.

For the Staging/Build environment, this environment is created parting from the current Production environment data backup, having some data being overwritten (as described at SPECIAL ENTITIES' ATTRIBUTES TO OVERWRITE).

PLANNED FOR: (Optional) Should specify a date (with UTC time zone specification), for which you want to plan/schedule the new Bizagi environment(s) to be available.

Notice that such date is not automatically guaranteed, mainly because requests still need to undergo revision and approval.

You may choose to skip this information, in which case it will be assumed an ASAP approach, and Bizagi will start to work on provisioning the new Bizagi environment(s) right away.

SPECIAL ENTITIES' ATTRIBUTES TO OVERWRITE: (Optional) Should specify if there are some attributes in certain entities of your data model, which you want their values changed. Applicable only to the Staging/Build environment.

You will need to specify exactly which attributes from which entities you want to consider special values and specify such values accordingly.

 

note_pin

Creating the new environment will take 1 to 2 days upon reception of the submitted form and given that the request is approved.

Once it is created, you will be notified back via e-mail.

 

CM03 - Resetting developer password

Whenever a developer can't access the Development environment or generally wants to reset the password of his/her account, fill out the following format (table) and submit it to cloud@bizagi.com.

 

CM03 - RESETTING DEVELOPER PASSWORD

SUBMITTER


CONTACT E-MAIL


DEVELOPER(S)


PLANNED FOR


 

Consider that:

SUBMITTER: Should specify the name of the contact who submits the request.

CONTACT E-MAIL: Should specify the e-mail of the contact who submits the request, and who will be notified once the change is applied.

DEVELOPER (S): Should specify the full name of the developer(s). Ensure you specify it as [First name Last name] so that you can separate with commas if there is more than one developer.

PLANNED FOR: (Optional) Should specify a date (with UTC time zone specification), for which you want to plan/schedule the change to apply.

Notice that such date is not automatically guaranteed, mainly because requests still need to undergo revision and approval.

You may choose to skip this information, in which case it will be assumed an ASAP approach, and Bizagi will start to work on the change right away.

 

note_pin

Resetting the password for developer access takes up to one day upon reception of the submitted form and given that the request is approved.

Once done, you will be notified back via e-mail.

 

 

CM04 - Granting developer access

Whenever a developer will no longer work on a given Bizagi project, fill out the following format (table) and submit it to cloud@bizagi.com.

 

CM04 - GRANTING DEVELOPER ACCESS

SUBMITTER


CONTACT E-MAIL


DEVELOPER(S)


BIZAGI PROJECT(S)


PLANNED FOR


 

Consider that:

SUBMITTER: Should specify the name of the contact who submits the request.

CONTACT E-MAIL: Should specify the e-mail of the contact who submits the request, and who will be notified once the change is applied.

DEVELOPER (S): Should specify the full name of the developer(s). Ensure you specify it as [First name Last name] so that you can separate with commas if there is more than one developer.

BIZAGI PROJECT (S): Should specify the name of the Bizagi project(s) to which you want to grant access to the new developer.

Note that you may specify more than one Bizagi project.

PLANNED FOR: (Optional) Should specify a date (with UTC time zone specification), for which you want to plan/schedule the change to apply.

Notice that such date is not automatically guaranteed, mainly because requests still need to undergo revision and approval.

You may choose to skip this information, in which case it will be assumed an ASAP approach, and Bizagi will start to work on the change right away.

 

note_pin

Granting access to a developer takes up to one day upon reception of the submitted form and given that the request is approved.

Once done, you will be notified back via e-mail.

 

CM05 - Revoking developer access

Whenever a developer will no longer work on a given Bizagi project, fill out the following format (table) and submit it to cloud@bizagi.com.

 

CM05 - REVOKING DEVELOPER ACCESS

SUBMITTER


CONTACT E-MAIL


DEVELOPER(S)


BIZAGI PROJECT(S)


PLANNED FOR


 

Consider that:

SUBMITTER: Should specify the name of the contact who submits the request.

CONTACT E-MAIL: Should specify the e-mail of the contact who submits the request, and who will be notified once the change is applied.

DEVELOPER (S): Should specify the full name of the developer(s). Ensure you specify it as [First name Last name] so that you can separate with commas if there is more than one developer.

BIZAGI PROJECT (S): Should specify the name of the Bizagi project(s) to which you want to revoke access from, to the given developer.

Note that you may specify more than one Bizagi project.

PLANNED FOR: (Optional) Should specify a date (with UTC time zone specification), for which you want to plan/schedule the change to apply.

Notice that such date is not automatically guaranteed, mainly because requests still need to undergo revision and approval.

You may choose to skip this information, in which case it will be assumed an ASAP approach, and Bizagi will start to work on the change right away.

 

 

note_pin

Revoking access to a developer takes up to one day upon reception of the submitted form and given that the request is approved.

Once done, you will be notified back via e-mail.