Project Overview

When you are ready to make process changes - either create your own, or start with one you see on the processes page and make minor changes - you will have to create a project.

While navigating the no-code platform you may have noticed “checkout” buttons for objects on various pages such as the “Business Process Home” page.

A “Ready for Checkout” button as it appears in the “Business Process Home” page header

To prevent multiple users trying to make changes at once, in order to make changes to business processes or other objects, the object must first be “checked out” by a user under a “Project”. Checking out an object gives the user permission to make any changes to it.

Projects are a unit of work created to assist in job management. A project serves as a way to combine all related objects including functions, processes, and entities, under one unit with a cohesive goal.

A “Project” groups all checked out sources together. It will force those sources to move through to the next environment together. This is necessary because in a project with multiple sources, if only a portion of them were to be released to the next environment, the deliverable could be negatively affected.

One of the main benefits of having separate projects for separate goals is for promotional reasons. When changes need to be made, only one project will have to be altered and promoted through multiple environments. This reduces the risk of changes causing issues with unrelated objects.

Projects can be created and managed using the “Projects” page under the “Settings” category.

The “Projects” page which lists the existing projects to choose from and offers an option to create a new project as well.

Projects Page

The “Projects” page is used for creating and managing projects and can be broken into 4 parts.

  1. Project Selection Dropdown: This dropdown is used to select an existing project, or use the “+” button to create a new project. The “Refresh” button is also found here and can be used to refresh the page as updates to the project are made.
  2. Project Promotion History: The project promotion history is shown using a series of green and red rectangles resembling what environment the project has been promoted through. For example, this history above shows that the “Warehouse Data Collection” project has been promoted from DV to QA and back to DV. The red “DV” rectangle indicates that this is the current location of the project.

The “Current Location” of the project is also stated below the promotion history. There are also two action buttons here to “View History” or “Promote”. The “View History” button will open a window which will give specific details regarding previous promotions, such as who promoted the project and the date and time it was promoted. The  “Promote” button will open a window allowing the current user to promote the project to the next environment. If the project is in QA there will also be a “Demote” button as well, which allows the user to demote the project back to DV.

  1. Object Management: This series of action buttons allows the user to manage the objects under this project:
  1. Add New Object: This button opens a widget allowing the user to create a new object directly under this project.
  2. Add Existing Object: This button opens a widget allowing the user to choose an existing object which will be added to the project.
  3. Undo Checkout All: This button will undo the checkout of all objects under the project. When an object is not checked out, it can not be edited.
  4. Import: This feature allows the user to import external objects.
  5. Export: This feature allows the user to export objects externally.
  1. Objects: The final part of the projects page lists all the objects that are currently checked out under the current project. Selecting the object will open the object. There is also a menu represented by three dots in the top right corner of the object which allows the user to “Change Project”, “Change User” or “Undo Checkout” for that specific object.

Promoting Projects

As projects are worked on, there are three environments the project will go through in order for the changes to be implemented. These three environments are: DV, QA, and PD.

DV Environment: The DV environment stands for “Development”, and is the environment used to make any changes or additions in the IDE. When a user creates a project and “checks out” objects, the project is checked out in the development environment.

QA Environment: The QA environment stands for “Quality Assurance” and is the environment used for testing any developmental changes made in the previous environment. Once the changes are made in DV, the project can be promoted to the “QA” environment. Here, no further changes can be made, but the platform  can be tested to ensure that any changes made won’t unintentionally cause issues in the application. This is helpful to avoid any changes breaking the live product version.

In cases where issues do arise during testing, the project can be demoted back down to the DV environment so that changes can be made to resolve any issues.

PD Environment: The PD environment stands for “Product” and is the environment that hosts the final product. This is where the changes can be implemented and the platform is fully functional for outside users to interact with.

Promotion History

When a project is promoted or demoted between environments, the details of the promotion are recorded as a promotion history, and can be accessed from the “Projects” page using a “View History” button.

The “View History” button opens a “Project History” widget which displays the project’s promotion path across the top, followed by a list of all path or environment changes.

For each environment change, the table lists the environment the project was moved to, the user who implemented the environment change, and the date and time the project was promoted (or demoted).

This can be useful to know when changes were implemented in case the path change does cause issues in one of the environments.

The “Project History” widget for the “test 2” project, which had been promoted to QA, and then demoted back to DV for further changes.