This document provides information on contracts, contract management, workspaces and workspace management. Additionally, it explains the basic application of this approach in solution life cycle, and what limited workspaces are. The following scheme shows how contracts and workspaces stand in solution hierarchy.
A client’s enclosed environment within a tenant is called a contract. It is usually backed by a formal contract, hence the name. Each client can have multiple contracts. A contract includes members, developer teams, and workspaces:
A workspace is a smaller enclosed environment that contains integration flows and credentials. Details on workspaces can be found here.
A member is a registered platform user that has been invited the contract by Owner and given a contract role. Members can collaborate or work individually.
A developer team is a smaller enclosed environment that contains component developers and their repositories.
Contracts are virtually separated from each other and require corresponding memberships to enter and work in. With the invitation a user gets a user role.
A tenant Admin can create contracts and set contract Owners. By default, only members with contract Owner or a other roles with the right permissions can manage contracts. However, roles can be customized, so in this document we will differentiate contract and workspace members by permissions.
Here is the full list of contract permissions:
Edit members in the contract
Create workspaces in the contract
View all workspaces in the contract
Delete workspaces in the contract
Edit contract repositories
Edit developer team
A client’s enclosed environment within a contract is called a workspace. Each contract can have multiple workspaces, and each workspace is virtually separated from other workspaces within a contract. A workspace includes members, credentials and integration flows:
A member is a user with certain access rights in the workspace. These rights are defined by user roles set by workspace Owner upon invitation of a contract member to a workspace.
An integration flow is a set of integration components and credentials used to synchronize data between multiple applications or services. More details on integration flows can be found here.
Contract members can be invited to a workspace within their contract by other members with the corresponding permissions. Members can contribute to integration flows in their workspace in collaboration with other members, or individually.
Any contract member can create workspaces. Only workspace Owner or member with corresponding permissions can manage workspaces. Here is the full list of workspace permissions:
Edit the workspace (including memberships)
Edit flows in the workspace
Toggle flow status between active and inactive
Toggle flow status between ordinary and real-time
Workspaces in a contract are separated from each other, but they can utilize the same components for their integration flows. This means that one can create similar integration flows in different workspaces within a contract. For non-disruptive testing one can create dedicated workspaces for testing and production stages, both running near-identical integration flows. The workspaces will have different credentials, so the testing stage may be accessed by the client’s engineers, and production environment is customer-facing only.
Workspaces can have the
Limited is intended for platform trial period. Workspaces with
limited type have certain restrictions for integration flows:
Integration flows in
limited workspaces are restricted by work time. This means that they are automatically stopped after a certain time. This time is defined for each installation with an environment variable.
limited workspaces, integration flows that contain errors will not be suspended. Instead, they will be stopped without saving any data.
Though not forbidden, it is highly unrecommended to use
limited workspaces for any production purposes.
Limited workspaces are indicated in the UI:
To change workspace type from
full, contact support.
Full is the default workspace type. However, the default type for workspaces created in a tenant can be changed. A user with corresponding permission can do that, using
full as a value.