Organizations

NOTE: This functionality is also available via our command line interface (CLI) tools. You may find it easier to use the CLI tools to perform some actions, such as inviting multiple users or exporting information into a machine-readable format.

What Is an Org?

An organization (or "org") is a DNAnexus entity used to manage a group of users. Use orgs to associate users, projects, and other resources with one another 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 necessary.

Org admins 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. You can create an orgs that is associated with a billing account by contacting sales@dnanexus.com.

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.

Org Membership Levels

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

  • ADMIN

  • MEMBER

An ADMIN-level user is granted all possible access in the org and may perform org administrative functions (e.g. adding/removing users or modifying org policies). A MEMBER-level user, 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.

Members

A user with MEMBER level can be configured to have a subset of the following org access. These access levels 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 mostUPLOAD 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.

Admins

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

Access

Level

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 abilities:

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 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.

Examples of Using Orgs

Visual example

In the diagram below, there are 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 a complicated organizational setup. Here users are grouped into two different billable orgs, with some users belonging to both orgs and others belonging to only one.

In this case, org-2 and org-3 bill their work against separate billing accounts. This separation of orgs can represent two different groups in one company working in different departments, each with their own budgets or purchase orders, two different labs that work closely together, or any other scenario in which two collaborators would share work.

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 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.

Example 1: Creating an org for sharing data

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 make 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 that they will all be given permission to view the dataset. If a member no longer needs access to the dataset, they can be removed from the org, and will then no longer have access to any projects or apps shared with org-dataset_access.

Example 2: Only admins can create projects

You can request sales@dnanexus.com to 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", and so 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 levels.

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

Example 3: Shared billing account

You can request sales@dnanexus.com to create a billable org where users work independently and bill all of their activities to the org billing account (as specified by the org admin). 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 with the org are stored in an "Org Resources" project that is shared with the org, which is granted VIEW access. The org can also have best-practice executables 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 user leaves your company or institution, their access to reference datasets and executables is revoked simply by removing them 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, contact support@dnanexus.com for more information about how orgs can work for you.

Managing Your Orgs

If you are an admin of an org, you can access the org admin tools from the Org Admin link in the header of the DNAnexus platform. From here, you can quickly navigate to the list of orgs you administer (via "All Orgs"), or to a specific org.

The Organizations list shows you the list of all orgs to which you have admin access. On this page, you can quickly see all of your orgs, the number of projects per org, and the funds available to the org. You can also see additional settings for each org by enabling optional columns (icon on the right side of the column headers).

Within an org, the "Settings" tab allows you to view and edit basic information, billing, and policies for your org.

View and update org information

You can find the org overview on the "Settings" tab. From here, you can:

  • View and edit the organization name (this is how the org is referred to in the UI and in email notifications)

  • View the organization ID, the unique ID used to reference a particular org on the CLI (e.g. org-demo_org)

  • View the number of org members, org projects, and org apps

  • View the list of organization admins

Managing org members

Within an org page, the "Members" tab allows you to view all the members of the org, invite new members, remove existing members, and update existing members' permission levels.

From the "Members" tab, you can quickly see the names and access levels for all org members. For more information about org membership, see the organization member guide.

Invite a new member

To add existing DNAnexus user to your org, you can use the "+ Invite New Member" button from the org's Members tab. This opens a screen where you can enter the user's username (e.g., smithj) or user-ID (e.g., user-smithj). Then you can configure the user's access level in the org.

If you add a member to the org with billable activities access set to billing allowed, they will have the ability to create new projects billed to the org.

However, adding the member will not change their default billing account. If the user wishes to use the org as their default billing account, they will have to set their own default billing account.

Additionally, if the member has any pre-existing projects that are not billed to the org, the user will need to transfer the project to an org if they wish to have the project billed to the org.

The user will receive an email notification informing them that they have been added to the organization.

Create new DNAnexus accounts

Org admins have the ability to create new DNAnexus accounts on behalf of the org. The user will then receive an email with instructions to activate their account and set their password.

NOTE: This feature is not available by default -- if you are an org admin, contact support@dnanexus.com for more information about provisioning user accounts.

If this feature has already been turned on for an org you administer, you will see an option to "Create New User" when you go to invite a new member.

Here you can specify a username (e.g. alice or smithj), the new user's name, and their email address. The system will automatically create a new user account for the given email address and add them as a member in the org.

NOTE: If you create a new user and set their Billable Activities Access to Billing Allowed, we recommend that you set the org as the user's default billing account. This option is available as a checkbox under the Billable Activities Access dropdown.

Edit member access

From the org "Members" tab, you can edit the permissions for one or multiple members of the org. The option to "Edit Access" appears when you have one or more org members selected in the table.

When you edit multiple members, you have the option of changing only one access while leaving the rest alone.

Remove members

From the org Members tab, you can remove one or more members from the org. The option to "Remove" appears when you have one or more org members selected on the Members tab.

Removing a member revokes the user's access to all projects and apps billed to or shared with the org.

Org Projects

In the org's Projects tab you to see the list of all projects billed to the org. This list includes all projects in which you have VIEW and above permissions as well as projects that are billed to the org in which you do not have permissions (Not a Member).

You can view all project metadata (e.g. the list of members, data usage, creation date), as well as some other optional columns (e.g. project creator). To enable the optional columns, select the column from the dropdown menu to the right of the column names.

Grant the admin access to org projects

In addition to viewing the list of projects, org admins can give themselves access to any project billed to the org. If you select a project in which you are not a member, you will still be able to navigate into the project's settings page. On the project settings page, you can click a button to grant yourself Administer permissions to the project.

You can also grant yourself Administer permissions if you are currently a member of a project billed to your org but you only have VIEW, CONTRIBUTE, or UPLOAD permissions.

Org Billing

View and update org billing contact

In the "Billing" section of the org "Settings" tab, you can set and update billing information for the org. To set the billing information for an org you administer, click on the "View/Edit Info" link for your org's billing account and fill out the form.

By setting the billing information for an org, you are designating somebody to be responsible for handling invoices sent by DNAnexus. This person can be you, somebody within your organization's finance department, or someone else. All invoices are sent to the person listed in the billing information.

Once you click the "Confirm billing" button, an email is sent to the billing email address asking for confirmation. Until the billing recipient activates the confirmation link contained in the email, your billing account is not updated.

View estimated charges

This section is only visible if your org is a billable org -- if it has confirmed billing information or has a non-negative spending limit remaining. The "Estimated Charges" section of the org allows org admins to view the total charges accumulated over the lifetime of an account.

The "Funds Left" shows org admins how much is left of the org's spending limit. If your org does not have a spending limit, your org is unlimited, and this box shows as “n/a.”

Set a spending limit

You can set or modify a spending limit for org activities. Spending limits can help you associate your activities on DNAnexus to a fixed budget amount or a purchase order.

As an org admin, you can use the "Set / Update Spending Limit" link in the "Funds Remaining" box to contact support@dnanexus.com to request a spending limit change.

NOTE: This is only a request to change the spending limit. The DNAnexus support team may follow up with you via email to clarify the change before it takes effect.

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 can 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 ensures that only the org admin is allowed to see the list of members and their access within the org and that org projects always remain under control of the org.

You can update org policies for your org in the "Policies and Administration" section of the org "Settings" tab. Here, you can both change the membership list visibility and restrict project transfer policies for the org and contact DNAnexus support to enable PHI data policies for org projects.

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 is an org that has confirmed billing information or a 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 are 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 are 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 is 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 level describes one of two membership levels available to users in an org, ADMIN or MEMBER.

  • 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.

  • 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 access is granted to a user to determine which actions the user can perform in an 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 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 can 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.