Permissions of Organization Members

All members of your Organization have "owner-level" access to any projects under the Organization's account. To make that concrete...

Let's say you have an Organization account with username your_org; it has members nick, chris, and matthew. That means nick, chris, and matthew will all have owner-level access to any your_org's projects, e.g., your_org/quick-start, your_org/project1.

They cannot, however, change the Organization's membership -- only you can do that.

Transferring projects to an Organization

Organization members can transfer ownership of a project to the Organization by clicking Settings from the project menu, then on the Archive Project or Transfer Ownership tab, clicking Change Project Owner. Enter the current owner and project name, then for the New owner username use the name of the Organization.

Organization Collaborators

If you add an organization as a collaborator to one of your projects, all members of the organization will be granted collaborator-level access.

Typical Uses for Organizations

Simple project access management

Project access management is the most common use for organizations in Domino.

Domino sees organizations and users as near-equivalents; the only real difference is that an organization contains multiple users. Because of this, organizations are a handy tool for simplifying project access for groups of users.

For example, inviting a team to join a project you are working on is as simple as creating an organization consisting of all the members of that team, and then adding the organization to the project. This is also useful in the event that you elect to remove the team from the project. You can also break up an existing organization into smaller groups, and then un-invite the original team while retaining the smaller, more relevant organization.

You can also use organizations to provide restricted access to your projects, instead of full access. For example, to give a team read-only access to a project, simply add the organization to your project and set its role to Results Consumer. If there's a group that should only be able to use Launchers, add the organization and give them Launcher User access.

Organization admins have the power to add or subtract people to their organization. Adding users to (or removing them from) organizations instead of each individual project that organization owns can be a real time-saver. Simply add or remove them once, at the organization level. Domino will take care of updating their access to each project for you.

Projects in production

Organizations are also a useful way to manage projects that have reached a “production grade”-level of quality. Users can set up organizations that are specifically intended to be homes for projects that are ready to be promoted to production, or that have already been promoted. Users working with projects owned by this organization will understand that these projects should be carefully documented and kept free of clutter. Any changes that are needed will require a fork and merge request process. Runs executed in these projects end up being very deliberate, with the purpose of updating data or models.

The process of using organizations to manage projects promoted to production can unfold in one of two ways. The first occurs when a project starts out as an individual user's project. That user invites others to this project, either individually or by using the Organizations feature, and over time other users come to find this project particularly useful. After a certain point, a decision is made that access to the project should be easier, and that it should be owned by the organization instead of the individual user.

The other path involves initial ownership of the project by an organization. This usually happens when the project is deemed to be important from the very beginning, and the project can best be built up by a group. As soon as this project is created, all users have access to all its resources, and project development proceeds mostly by forking and merging. Execution of code is still done in the organization-owned project as a way to check in your analysis or results.

Some Domino customers do this even for models that are not actually in production, as a way of submitting their work to be counted.

Sharing compute environments

One of the advantages of organizations is that they streamline and simplify the practice of sharing compute environments. Project owners who are members of an organization can use all of that organization’s compute environments for their own projects.

For example, if a user is a member of a corporate organization, whatever environments that organization’s admins have created will be available to the user for their own projects. Domino does not constrain users to membership in just one organization. If a user is a member of two organizations - a ‘corporate organization’ with production environments and an ‘R&D organization’ with more cutting edge environments  - that user has access to the compute environments of both organizations, as well as any global environments and environments the user already owns directly.

What would happen if this user were to be removed from an organization he was a member of, even though several of his projects rely on that organization’s environments? In that case, the now-unavailable environments would be reset to the user’s default environment. Domino sends a notification to any affected users whenever this happens.