Organizations on DNAnexus

What is an org

Video Tutorial: Introduction to Orgs

An org (or "organization") is a DNAnexus entity that is used to manage a group of users. At a high level, orgs can be used to associate users, projects, and other resources with each other in a way that models real-world collaborative structures. Orgs simplify management of access, sharing, and billing.

In its simplest form, an org can be thought of as an "alias" to refer to a group of users. This "alias" can be used to efficiently share projects and data with multiple users -- and to quickly revoke access if need be.

Org admins are administrators of an org who can manage org membership, configure access and projects associated with the org, and oversee billing. All storage and compute costs associated with an org are invoiced to a single billing account designated by the org admin.

Orgs are referenced on the DNAnexus platform by a unique org ID (e.g. org-dnanexus). Org IDs are used when sharing projects with an org in the UI or manipulating the org in the CLI.

Back to top of page

Org structure

In the picture below, we show 3 examples of how organizations can be structured.

3 examples of how organizations can be structured

Org-1

The simplest example, org-1, is represented by the leftmost circle. In this situation, org-1 is a billable org that has 3 members who share one billing account, so all 5 projects created by the members of org-1 are billed to that org. There is one admin who manages org-1, represented here as user A.

Org-2 and Org-3

The second example shows org-2 and org-3 demonstrating more complicated organizational setups. Here we group users into two different billable orgs, with some users belonging to both orgs and others belonging to only one.

This separation of orgs can represent two different groups in one company working in different departments, each with their own budget or purchase orders. In this case, org-2 and org-3 bill their work against separate billing accounts.

Org-2 has 5 members, 4 projects, and is managed by one org admin (user G). Org-3 has 5 members and 3 projects, but is managed by 2 admins (users G and I).

In this example, admin G and one other member, member H, belong to both org-2 and org-3. They can create new projects billed to either org, depending on the project they're working on. Admin G can manage users and projects in both org-2 and org-3.

Back to top of page

Org membership

Org membership levels

Users may have one of two membership levels in an org:

  1. ADMIN
  2. MEMBER

A user with ADMIN level is granted all possible access in the org and may perform org administrative functions (e.g. adding/removing users or modifying org policies). A user with MEMBER level, on the other hand, is granted only a subset of the possible org accesses in the org and has no administrative power in the org.

MEMBER

A user with MEMBER level can be configured to have a subset of the following org access. These access determine which actions each user can perform in an org.

Access Description Options
Billable activities access If allowed, the org member can create new projects and apps billed to the org, download data (incurring data egress charges against the org), and set their own default billing account to that of the org. [Allowed] or [Not Allowed]
Shared apps access If allowed, the org member will have access to view and run apps in which the org has been added as an "authorized user." [Allowed] or [Not Allowed]
Shared projects access The maximum access level a user can have in projects shared with an org. For example, if this is set to UPLOAD for an org member, the member will have at most UPLOAD access in projects shared with the org, even if the org was given CONTRIBUTE or ADMINISTER access to the project. [NONE], [VIEW], [UPLOAD], [CONTRIBUTE] or [ADMINISTER]

These accesses allow you to have fine-grained control over what members of your orgs can do in the context of your org.

ADMIN

Org admins are granted all possible access in the org. More specifically, org admins receive the following set of accesses:

Billable activities access Allowed
Shared apps access Allowed
Shared projects access ADMINISTER

In addition to the access listed above, org admins have the following additional access:

List and view metadata for all org projects

Org admins can list and view metadata for all org projects -- projects billed to the org -- even if the project is not explicitly shared with them. They can also give themselves access to any project billed to the org. For example, when a member creates a new project project-P and bills it to the org, he is the only user with access to project-P. The org admin will be able to see all projects billed to the org, including project-P. The org admin can also invite herself to project-P at any time to get access to objects and jobs in the project.

Become a developer for all org apps

Org admins can add themselves as a developer to any org app -- an app billed to the org. For example, when a member creates a new app app-A billed to the org, he is the only developer for app-A; however, any org admin may add herself as a developer at any time.

Back to top of page

Examples of using organizational memberships and access

Case 1: Orgs for sharing

You can create a non-billable org as an alias for a group of users. For example, you have a group of users who all need access to a shared dataset, Cancer Cell Lines. You can have an org which represents all the users who need access to the dataset, org-dataset_access, and share all the projects and apps related to the dataset with that org. All members of the org will have at least VIEW "shared project access" and "shared app access" so they will all be given permissions to view the dataset. If a member no longer needs access to the dataset, they can be removed from the org, and will no longer have access to any projects or apps shared with org-dataset_access.

Case 2: Only admins create projects

You can create a billable org where only one member, the org admin, can create new org projects. All other org members will not be granted the “billable activities access”, so they cannot create new org projects. The org admin can then assign each org member a “shared projects access” (VIEW, UPLOAD, CONTRIBUTE, ADMINISTER) and share every org project with the org with ADMINISTER access. The members' permissions to the projects will be restricted by their respective “shared project access”.

For example, in a given group, bioinformaticians can be given CONTRIBUTE access to the projects shared with the entire org, so they can run analyses and produce new data in any of the org projects. However, the sequencing center technicians only need UPLOAD permissions to add new data to the projects. Analysts in the group will only be given VIEW access to projects shared with the org. When you need to add a new member to your group and give them access to the projects shared with the org, you simply need to add them to the org as a new member and assign them the appropriate permission sets.

This membership structure allows the org admin to control the number of projects which are billed to the org. She can also quickly share new projects with her org and quickly revoke permissions from users who are removed from the org.

Case 3: Shared billing account

You can have an billable org where users work independently, billing all their activities to the org billing account. All org members are granted “billable activities access”. The org members also need to share common resources (e.g. incoming samples or reference datasets).

In this case, all members should be granted the “shared apps access” and assigned VIEW as their "shared projects access”. The reference datasets that need to be shared are stored in a "Org Resources" project that is shared with the org with VIEW access. The org can also have best practice executables that are built as apps on the DNAnexus system.

The apps can be shared with the org so all members of the org have access to these (potentially proprietary) executables. If any person leaves your company or institution, their access to reference datasets and executables is revoked simply by removing their user from the org.

Other cases

In general, it is possible to apply many different schemas to orgs as they were designed for many different real-life collaborative structures. If you have a collaboration you would like to support, please contact support@dnanexus.com for more information about how orgs can work for you.

Org policies

Org admins can also set configurable policies for the org. Org policies dictate many different behaviors when the org interacts with other entities. The following policies exist:

Policy Description Options
Membership List Visibility Dictates the minimum org membership level required to view the list of org members, their membership level, and access within the org. If PUBLIC, any DNAnexus user will be able to view the list of org members. [ADMIN], [MEMBER], or [PUBLIC]
Project Transfer Dictates the minimum org membership level allowed to change the billing account of an org project (via the UI or project transfer). [ADMIN] or [MEMBER]

DNAnexus recommends, as a starting point, to restrict the “membership list visibility policy” to ADMIN and “project transfer policy” to ADMIN. This will ensure that only org admin will be allowed to see the list of members and their access within the org and that org projects will always remain under the control of the org.

Org Guides

For more information on orgs, how to interact with orgs you belong to, and how to manage orgs you administer, please see the guides listed below.

Glossary of Org Terms

Billable activities access is an access level that can be granted to org members. If allowed, the org member can create new projects and apps billed to the org, download data (incurring data egress charges against the org), and set their own default billing account to that of the org.

Billable org describes an org that has confirmed billing information or a non-negative spending limit remaining. Users with billable activities access in a billable org will be allowed to create new projects billed to the org. See the definition of a non-billable org for an org that is used for sharing.

Billed to an org (app context) sets the billing account of an app to an org. Apps require storage for their resources and assets, and the billing account of the app will be billed for that storage. The billing account of an app does not pay for invocations of the app unless the app is run in a project billed to the org.

Billed to an org (project context) sets the billing account of a project to an org. The org will be invoiced the storage for all data stored in the project as well as compute charges for all jobs and analyses run in the project.

Membership list visibility policy dictates the minimum org membership level required to view the list of org members, their membership level, and access within the org.

Membership level describes one of two membership levels available to users in an org, ADMIN or MEMBER.

Non-billable org describes an org only used as an alias for a group of users. Non-billable orgs do not have billing information and will not have any org projects or org apps. Any user can share a project with a non-billable org.

Org admin describes administrators of an org who can manage org membership, configure access and projects associated with the org, and oversee billing.

Org app is an app billed to an org.

Org ID is the unique ID used to reference a particular org on the DNAnexus platform (e.g. org-dnanexus).

Org member is a DNAnexus user associated with an org. Org members can have variable membership levels in an org which define their role in the org. Org members include org admins.

Org access is granted to a user to determine which actions the user can perform in an org.

Org policy is a configurable policy for the org. Org policies dictate many different behaviors when the org interacts with other entities.

Org project describes a project billed to an org.

Org (or "organization") is a DNAnexus entity that is used to associate a group of users. Orgs are referenced on the DNAnexus platform by a unique org ID.

Project transfer policy dictates the minimum org membership level allowed to change the billing account of an org project.

Share with an org means to give the members of an org access to a project or app via giving the org access to the project or adding the org as an “authorized user” of an app.

Shared apps access is an org access level that can be granted to org members. If allowed, the org member will be able to view and run apps in which the org has been added as an "authorized user".

Shared projects access is an org access level that can be granted to org members. The maximum access level a user can have in projects shared with an org.

Last edited by Thanh-Ha Nguyen, 2017-02-07 23:55:39

 Feedback