Organizations in Kinvey are used to group Kinvey entities (applications, services, websites, etc.), manage collaboration for those entities and apply licensing restrictions.
If your company is a digital agency producing applications for many customers, you could create an organization for each of your customers. You can then group all Kinvey backend entities for a customer under their own organization. You will then be able to get the proper license for each of your customers and manage user access independently.
Only a user with the Administrator role on instance level can create organizations. If you need an organization on a multi-tenant Kinvey instance, please contact Kinvey Support.
The licensing in Kinvey is handled on organization level. Each organization has a license assigned to it. All applications, services and websites in the organization are subject to the restrictions of that license.
Some sample restrictions are:
- number of applications
- number of environments per application
- number of application users
- application data storage limit
Each Kinvey user gets their own personal organization. The purpose of this organization is to provide playground for testing backend configurations. The personal organizations are not limited in functionality, but have limitations on load/performance. They are not meant for production apps.
Personal organizations are named after the Kinvey user that they were created for. If the user did not enter their name, their email is used. When the personal organization is created, the user it was created for is set as an Administrator for the organization.
On multi-tenant instances, the personal organizations have the Kinvey trial license assigned. This license is meant for trying out the product and expires after 30 days. On single-tenant instances, personal organizations are using a non-expiring, but still limited license.
Organization administrators have the ability to invite users to the organization, as well as to revoke their access and determine their organization role. Once a user is part of the organization, they can be given additional access to collaborate in specific applications, services or websites.
Note: removing a user from the organization also revokes their access to all lower-level entities (applications, services and websites) in the organization. Regardless of the role of the user on the lower level, they need to be part of the organization in order to collaborate.
Organization User Roles
The following user roles are available on organization level:
|Role name||Description||Legacy name|
|Member||Makes the user a member of the organization but does not grant any organization-level permissions.||COLLABORATOR|
|Viewer||Grants access to view the organization and Viewer access to all of its sub-entities.||N/A|
|Collaborator||Grants access to view an organization and Collaborator access on all of its sub-entities.||N/A|
|Developer||Grants access to view an organization and Developer access on all of its sub-entities.||N/A|
|Administrator||Grants full access to manage an organization and all of its sub-entities.||ADMIN|
for more information on what Viewer, Collaborator and Developer access levels give, please look into application roles, service roles or website roles.
Several legacy roles are also available. We do not recommend using those roles, but we have not removed them because of backward compatibility. They are suffixed with the word "_Legacy". Here is the list of legacy roles:
|Role name||Description||Previous name|
|MEMBER_Legacy||Grants permissions to create applications and view all services and websites.||MEMBER|
|BACKEND_DEV_Legacy||Grants permissions to create applications, services and web sites and collaborate on all existing services and web sites.||BACKEND_DEV|
|ADMIN_Legacy||Grants permissions to create applications, services and web sites, collaborate on all existing services and web sites and manage organization members and configuration.||ADMIN|
|APP_CREATOR_Legacy||Grants permissions to create applications. Usually used in conjunction with the Member role.||APP_CREATOR|
|SERVICE_CREATOR_Legacy||Grants permissions to create services. Usually used in conjunction with the Member role.||SERVICE_CREATOR|
|SITE_CREATOR_Legacy||Grants permissions to create web sites. Usually used in conjunction with the Member role.||SITE_CREATOR|
A team represents several users logically grouped together. Teams can help with organizing and managing the permissions in an organization.
Instead of assigning a set of roles to each user, you could group your users logically into several teams. You can then assign each team the required roles. This way you could easily change the roles of the whole group at a later point. Also, you will be able to easily add more users in the teams or remove users who are no longer part of the team and will not need the access that it provides.
For single-tenant instances, it is also possible to automatically put users in the appropriate teams, based on their groups from an external identity provider.
Organization administrators can manage the organization configuration. It includes some security-related settings, an option to set a list of administrative contacts as well as the ability to rename and delete the organization. The configuration options are:
Require admin approval for user accounts
Specifies whether an approval from administrators is required for new users to join the organization.
Require email verification
Specifies whether users need to verify their email before thay can log in with their account.
User session timeout
The default session time for application users. This setting can also be overridden on application level.
A list of administrative contacts for the organization. They will receive emails for newly released features, planned deprecations, scheduled service maintenance and other important changes.
To change organization settings:
- In Kinvey Console, click the Organization settings icon in the top navigation bar.
- Select the organization from the list on the left.
- In the main pane, select the Settings tab.