Setting up your environment
Exactly how you will want to manage your Org to enable version control and environment promotion will depend on your use case and which package of Tray you are working with.
Workspaces as environmentsCopy
If you are a Team or Enterprise customer building internal automations, you can generally make use of shared workspaces to manage your environments.
Team / Enterprise setupCopy
The following diagram shows a multiple workspace setup whereby you have dev and prod workspaces for each department.
Workspaces can be created and used to sub-divide your organization, for example:
Company departments (sales, marketing, HR etc.)
Internal teams
A bespoke integration for a customers.
Feature | Notes | Limitations |
|---|---|---|
Users (RBAC) | Control what access each user has access to which env/workspace | |
Auths | Auths are only available to users in that workspace | |
Promotion method | Export project from department dev and import to department prod workspace | |
Custom services | Create in organization workspace to make available to all workspaces | |
Custom connectors | Create in organization workspace to make available to all workspaces |
Pro customer setupCopy
The following diagram shows a setup appropriate for a smaller company (possibly on a pro account with a limited number of workspaces) whereby you:
Create one dev workspace for all dev projects
Create one other production workspace for all prod projects
Feature | Notes | Limitations |
|---|---|---|
Users (RBAC) | Users in dev workspace have access to all dev projects and auths. Same for prod workspace users | Unable to assign different roles to users per project within an environment |
Auths | Dev workspace auths are available to be used in all dev projects. Same for prod workspace auths | Cannot limit auth access per project within an environment |
Promotion method | Export from project in dev, import to project in prod | |
Custom services | Custom services can be made available to both dev and prod workspaces | |
Custom connectors | Custom connectors can be made available to both dev and prod workspaces |
Embedded integrations setupCopy
For Enterprise customers building out Embedded integrations, it is not currently possible to create Solutions in custom shared workspaces.
In order to manage multiple integrations you will need to decide between two approaches:
Accounts/orgs as environmentsCopy
In this setup you will need to request multiple Tray orgs to act as e.g. dev, staging and prod.
Each integration is then promoted from the 'Embedded' workspace of one account to the next.
This is the most common setup for Embedded environment control, and is most effective in terms of segragating users, auths, test vs live data and End Users
Custom assets (services, service environments (OAuth apps) and custom connectors) are somewhat tricky to manage, however.
Feature | Notes | Limitations |
|---|---|---|
Users (RBAC) | Users in dev account have access to all dev projects and auths. Same for prod account users | Unable to assign different roles to users per project |
End Users | Use Test End Users in staging/dev environments so that billing is not affected | |
Auths | Dev workspace auths are available to be used in all dev projects. Same for prod workspace auths | Cannot limit auth access per project within an environment |
Promotion method | Export from project in dev, import to project in prod | |
Custom services | May need to create in each account | |
Custom connectors | If using a custom service, may need to create in each account | During env promotion, need to edit json exports to change connector details |
Tokens | Each env has its own token - use separate master tokens to connect with dev and prod in your codebase |
Projects as environmentsCopy
This setup might be appropriate for customers with a small (<=5) number of integrations.
It is simpler for custom services, custom service envs (OAuth apps) and custom connectors.
However, you will have to use Solution tags to segregate as you are using the same master token for both environments.
And it is not possible to fully segregate users, permissions and test / live data.
Feature | Notes | Limitations |
|---|---|---|
General setup | Use labels/naming convention to associate Projects + Authentications with environment | |
Users (RBAC) | All users are part of the Embedded org workspace | Unable to assign different roles to users per environment |
End Users | Use Test End Users in staging/dev environments so that billing is not affected | |
Auths | All auths are available to all users | Cannot limit auth access per evironment |
Promotion method | Export/import project from one project to another | |
Custom services | Can create and use in all projects/environments | |
Custom connectors | Can create and use in all projects/environments | |
Tokens | Each env doesn't have its own token |