An organization (or "org") is a DNAnexus entity used to manage a group of users. Use orgs to group users, projects, and other resources together, in a way that models real-world collaborative structures.
In its simplest form, an org can be thought of as referring to a group of users on the same project. An org can be used efficiently to share projects and data with multiple users - and, if necessary, to revoke access.
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 org that is associated with a billing account by contacting [email protected].
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 Platform user interface or when manipulating the org in the CLI.
Users may have one of two membership levels in an org:
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.
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.
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 member 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.
Org admins are granted all possible access in the org. More specifically, org admins receive the following set of accesses:
Billable activities access
Shared apps access
Shared projects access
In addition to the access listed above, org admins have the following additional abilities:
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 themself to Project-P at any time to get access to objects and jobs in the project.
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 themself as a developer at any time.
In the diagram below, there are 3 examples of how organizations can be structured.
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.
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. You can make an org which represents all the users who need access to the dataset, for example an org named 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.
You can request [email protected] 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. The org admin can also quickly share new projects with their org and revoke permissions from users who have been removed from the org.
You can request [email protected] 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.
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 type of collaboration you would like to support, contact [email protected] for more information about how orgs can work for you.
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.
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 Platform user interface and in email notifications).
View the organization ID, the unique ID used to reference a particular org on the CLI (e.g.
View the number of org members, org projects, and org apps.
View the list of organization admins.
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.
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.
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.
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.
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.
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.
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.
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.
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 of).
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.
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.
To access your org's billing information:
From the global menu shown at the top of the screen, click org admin and then click the name of the org you want to view.
Click Billing from the org details screen to view billing information.
To set the billing information for an org you administer:
Navigate to the Billing tab according to the instructions above.
Click on the Add Billing Info button under the section named Organization Billing, and follow the instructions listed.
You can set or modify a spending limit for an org's usage charges. Spending limits can help you associate your activities on DNAnexus to a fixed budget amount or a purchase order.
To set a spending limit:
Click on Org Admin from the global menu bar and then click on your org name.
Once on your org page, click on the billing tab.
Click the Set / Update Spending Limit link in the Funds Left box to contact [email protected] to request a spending limit change. 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.
The Funds Left section shows how much is left of the org's spending limit. If your org does not have a spending limit, your org is unlimited, which shows up as “n/a.”
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:
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]
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]
Dictates the minimum org membership level allowed for a user to invite that org to a project
[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.
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 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. Note that ADMINISTER is a type of access level.
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 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. Admins are a type of org member as well.
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.