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:
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.
There are two types of workspaces: limited and full. Use full workspaces for the production purposes and limited workspaces for the development purposes.
The full workspaces have no time restrictions on integration flows. Flows in limited workspaces may only run for a limited amount of time before being automatically stopped. Check the separate section for restrictions on limited workspaces.
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
Edit credentials
You can learn more about workspace management here.
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.
Limited workspaces have certain restrictions for integration flows:
We recommend not to use limited workspaces for the production purposes. Use full workspaces instead.
The limited workspaces are marked in the platform UI:
To change workspace type from limited to full, contact our support team or your tenant administration.