Sharing and access

Access in Domino stacks. To use a Dataset, Data Source, or External Data Volume (EDV) inside a Project, you need access to the Project and to that entity. Neither substitutes for the other: a collaborator who was never granted the Dataset cannot read it, and holding the Dataset does not let you into the Projects that use it. That is why an invitation is sometimes not enough. When a collaborator lacks permission on a Data Source the Project uses, Domino flags it on the Project’s Data page and on the Data tab in a Workspace. The fix is for the entity’s owner to grant access, not for you to invite the person to the Project again.

Who grants access to each entity

Whoever owns an entity grants access to it, except where only an administrator can. An administrator alone grants an External Data Volume, shares a Data Source with everyone in the deployment, and makes a Compute Environment globally accessible.

Entity	Who grants access	How access is granted
Project	The owner sets visibility; the owner or any contributor invites collaborators	A visibility level of Public, where anyone with the URL can view the files and runs without a Domino account, Searchable, where the name and description appear in search but the contents stay hidden, or Private, where only collaborators can find it at all. On top of that, named collaborators and organizations, each holding a collaborator role
Dataset	The Dataset owner	An Owner, Editor, or Reader role granted to users and organizations
Data Source	The Data Source owner, or an administrator	Specific users or organizations; an administrator can instead share it with everyone in the deployment
External Data Volume	An administrator only	The Volume Access setting: everyone in the deployment, or specific users and organizations. A separate Mount as read-only setting decides whether you can write to it
App	A Project contributor or owner	Edit rights are inherited from the parent Project. View rights are set on the App itself: Restricted to named viewers and Project collaborators, optionally Globally discoverable so other users can request access, or Anyone in Domino
Compute Environment	Whoever creates the environment; an administrator for Globally Accessible ones	A visibility level of Private, Available to an Organization, or Globally Accessible

Only the Project owner can change a Project’s visibility. Some deployments also reserve collaborator management for Project owners alone, in which case contributors do not see the Invite button.

Public visibility exposes a Project’s files and runs to anyone with the URL, with no Domino account required, though only collaborators can start runs. Selecting Allow runs by anonymous users on top of it lets anyone run your code. Check what the Project reveals, including environment variables holding bearer tokens, API keys, and passwords, before you allow anonymous runs.

Domino does not control access to an external Git repository attached to a Project. Manage that in your Git host.

All of this sits on top of the global role an administrator assigns you. Practitioner, the role every user starts with, is what lets you create Projects, run Jobs, start Workspaces, and publish Apps in the first place. See Administer identity and access control for the administrator’s side: identity providers, role assignment, service accounts, and the deployment settings that change what any of this allows. An organization is a named group of users that Domino permissions as a single unit. Grant access to an organization rather than to named individuals whenever a team, not a person, is what needs it. You grant it once, and membership does the rest.

Add an organization as a Project collaborator and every member holds that collaborator role.
Change the membership and Domino updates each member’s Project access for you.
Every member holds owner-level access to the Projects owned by the organization’s own account, so a Project owned by an organization is open to all of its members.
A Project owner who belongs to an organization can use that organization’s Compute Environments. Losing membership resets the affected Projects to your default environment, and Domino notifies you.

An organization is owned by the user who created it. That owner adds and removes members and can make another user an owner; other members cannot change the membership, and platform administrators can change any organization’s. In deployments that synchronize Security Assertion Markup Language (SAML) groups to organizations, membership follows the directory instead. Manage organizations covers creating one and the patterns it supports, including holding production-grade Projects under an organization rather than a person. Your deployment can also narrow who you are allowed to invite to a Project to members of your own organizations. If a person you expect to find is not offered, that setting is the reason.

Authenticate scripts and pipelines

A script, notebook, or pipeline authenticates with its own credential instead of a browser session, and it reaches exactly what that credential’s identity already reaches. A credential never widens access.

	Personal Access Token	Domino Service Account
Who creates it	You, from your own account settings	An administrator, through the Domino API
Whose identity it uses	Yours	A technical user that cannot sign in to the web interface or the CLI
Which roles it carries	The roles you hold. Changing your roles revokes the token instead of updating it	The roles the account held when the token was issued; later role changes do not reach tokens already issued
How long it lasts	However long you choose when you create it	Four months by default
Use it for	Your own scripts, notebooks, and Jobs	Continuous integration and continuous delivery (CI/CD) pipelines, monitoring and automation tools, and system-to-system integrations

Create a Personal Access Token under Account, then Account settings, then Personal Access Token. Pick an expiration and copy the value at that moment: Domino never shows it again, and no administrator can retrieve it for you.

Changing your roles revokes every Personal Access Token you hold. If an administrator adjusts them, your scripts, notebooks, and scheduled Jobs stop authenticating until you create replacement tokens.

Best practice: keep Personal Access Tokens for your own work and ask an administrator for a Domino Service Account for anything shared. A service account’s tokens belong to no individual, so deactivating a departing employee never breaks a pipeline.

Manage organizations: create an organization and use it to hold Projects, access, and Compute Environments.
Collaborate on Projects: invite collaborators and see what each Project role can do.
Share data securely: the full permission model for Datasets, Data Sources, and External Data Volumes.
App security: view and edit rights on a published App, and the identity headers it receives.
Domino Service Accounts: what a service account can do, and what to ask an administrator for.
Domino API authentication: create, use, and revoke a Personal Access Token.
Protecting tokens and API keys: store and rotate credentials without exposing them in code.

Core Concepts

Features

Sharing and access

Who grants access to each entity

Authenticate scripts and pipelines

​Who grants access to each entity

​Share with an organization

​Authenticate scripts and pipelines

​Related

Who grants access to each entity

Share with an organization

Authenticate scripts and pipelines

Related