Skip to main content

Access Management

This page explains the controls that VIKTOR has to manage access to data and logic. These are divided in three categories: environment, workspace and app. The difference between workspaces and apps is explained here.

Environment access

Access to the environment can be setup in two ways:

  • login with username and password
  • Single Sign-On (for more info see this page)

Environment rights

Each user has two access attributes that determine the role they have. The possible combinations, together with their name are listed below. The matrix with their permissions is shown below.

Access levelDeveloper accessRole
UserInternal user
UserInternal developer*
AdminAdmin user
AdminAdmin developer*
External userExternal user
External userExternal developer*

* Developer access is an addition on top of normal user access

external userexternal developerinternal userinternal developeradmin useradmin developer
invite users to organizationnnnnyy
edit users on organizationnnnnyy
remove usersnnnnyy
create workspacennnnyy
edit workspaceif workspace adminif workspace adminif workspace adminif workspace adminyy
archive workspacennnnyy
manage users in workspaceif workspace adminif workspace adminif workspace adminif workspace adminyy
access private workspacewhen invitedwhen invitedwhen invitedwhen invitedyy
access internal workspacennyyyy
access public workspaceyyyyyy
view activity dashboardnnnnyy
list and modify workersnnnnyy
see appstorennyyyy
create appnnnyyy
publish app versionnif maintainernif maintainerny

Besides rights on the environment, there are more granular controls on workspaces and apps.

Workspace access

Access to the workspace is managed by setting the visibility of the workspace:

  • private: invited users see the workspace and have access
  • internal: everyone inside the company (excluding external users) can see and access the workspace
  • public: everyone can access the workspace using the URL (also people not logged in)

Workspace rights

Workspace rights (what can a user do when they enter the workspace) are configured using usergroups. You define what this usergroup is allowed to do and assign users to this group. The possibible permissions per object type are:

categorydetailexplanation
ReadNavigateMinimum (navigation) access, excluding summary info and excluding editor access
ReadBasicMakes an object and its summary information accessible to a user, not including the editor
ReadAllGives access to all object information including the editor
WriteCreateAllows the user to create an object
WriteUpdateAllows the user to update an object
WriteRenameAllows the user to rename an object
DeleteAllows the user to delete an object

Usergroup assignment differs between internal and private workspaces:

  • private workspaces: users are explicitly invited to get access. During invitation, the appropriate usergroup (and thus access level) is selected
  • internal workspaces: users automatically get access when they are invited to the environment. They are added to the default user group of each internal workspace. This default can be configured per workspace.

Workspace admin

The administration of a workspace can be delegated to a specified "Workspace admin", which is assigned from the users on the workspace.

This workspace admin can:

  • invite users (in the case of private workspace)
  • set access levels for the users
  • assign other workspace admins

App accesss

All users (except for external users/developers) can access the app store and find the applications that have been created. Here they can checkout app details and learn about the application and which developers maintain the app.

Apps are not used by users directly, these are workspaces (see this explanation). The apps only contain the logic, without data and no users. Users can contact (one of) the maintainers, to get access.

Internal developers and admin users can create apps. Developers are automatically assigned as the first maintainer on the app.

App rights

Only app maintainers can publish new versions of an app. They are treated as being allowed to have access to the code. This means that error reports (with tracebacks containing code) are available to them.

App maintainers are not allowed to create workspaces. They can use their development workspace when developing, but need explicit access to relevant workspaces to get access to production data.