---
title: Workflow overview
description: Overview of typical admin workflow for creating user accounts, defining groups, assigning access roles, monitoring and managing worker allocation, and more.

---

# DataRobot overview and administrator workflow {: #datarobot-overview-and-administrator-workflow }

DataRobot sets up the basic deployment configuration, which defines the available system-wide features and resource allocations. The following describes the typical admin workflow for setting up users on DataRobot:

=== "SaaS"

	1. Log in using the default administrator account and create an Admin account.
	2. [Create user accounts](manage-users), starting with your own.
	3. Set [user permissions](manage-users#set-admin-permissions-for-users) and [user roles](manage-users#rbac-for-users).
	4. *Optional*. [Create groups](manage-groups) and add [multiple users](manage-groups#add-users-to-a-group) or add users [individually](manage-users#manage-groups-and-organization-membership).
	5. *Optional*. [Manage personal worker allocation](#change-personal-worker-allocation), which determines the maximum number of workers users can allocate to their project.

	See also:

	* [Common administrator tasks](admin-guide/index) to troubleshoot or prevent issues.
	* [Monitoring and managing users](main-uam-overview)

=== "Self-Managed"

  	1. Log in using the default administrator account and create an Admin account.
  	2. [Create user accounts](manage-users), starting with your own.
  	3. Set [user permissions](manage-users#set-admin-permissions-for-users) and [user roles](manage-users#rbac-for-users).
  	4. *Optional*. [Create groups](manage-groups) and add [multiple users](manage-groups#add-users-to-a-group) or add users [individually](manage-users#manage-groups-and-organization-membership).
  	5. *Optional*. To control and allocate resources, [create organizations](manage-orgs) and add [multiple users](manage-orgs#orgs-addusers) or add users [individually](manage-users#manage-groups-and-organization-membership).
  	6. *Optional*. Configure SAML SSO.
  	7. *Optional*. [Manage personal worker allocation](#change-personal-worker-allocation), which determines the maximum number of workers users can allocate to their project.

  	See also:

  	* [Common administrator tasks](admin-guide/index) to troubleshoot or prevent issues.
  	* [Monitoring and managing the cluster and users](manage-cluster/index)
  	* [Monitoring and managing users](main-uam-overview)


## Important concepts {: #important-concepts }

The following sections explain concepts that are an important part of the Self-Managed AI Platform setup and configuration. Later sections assume you understand these elements:

* [Workers and worker allocation](#what-are-workers)
* [About groups](#what-are-groups)
* [About organizations](#what-are-organizations)

A DataRobot project is the combination of the dataset used for model training and the models built from that dataset. DataRobot builds a project through several distinct phases.

During the first phase, DataRobot imports the specified dataset, reads the raw data, and performs EDA1 (Exploratory Data Analysis) to understand the data. The next phase, EDA2, begins when the user selects a target feature and starts the model building process. Once EDA2 completes, DataRobot ranks the resulting models by score on the model Leaderboard.

## What are workers? {: #what-are-workers }

*Workers* are the processing power behind the DataRobot platform, used for creating projects, training models, and making predictions. They represent the portion of processing power allocated to a task. DataRobot uses different types of workers for different phases of the project workflow, including DSS workers (Dataset Service workers), EDA workers, secure modeling workers, and quick workers. All workers, with the exception of modeling workers, are based on system and license settings. They are available to the installation's users on a first come, first served basis. Refer to the *Installation and Configuration* guide (provided with your release) for information about those worker types. This guide explains how to monitor and manage *modeling workers*.

During EDA2, modeling workers train data on the target feature and build models. Modeling worker allocation is key to building models quickly; more modeling workers means faster build time. Because model development is time and resource intensive, the more models that are training at one time, the greater the chances for resource contention.

### Modeling worker allocation {: #modeling-worker-allocation }

The admin and users each have some ability to modify modeling worker allocation. The admin [sets a total allocation](#change-personal-worker-allocation) and the user has the ability to set per-project allocations, up to their assigned limit. Note that modeling worker allocation is independent of hardware resources in the cluster.

Each user is allocated four workers by default. This "personal worker allocation" means, at any one time, no more than four workers (if left to the default) are processing a user's tasks. This task count applies across all projects in the cluster&mdash;multiple browser windows building models are all a part of the personal worker count, more windows does **not** provide more workers.

The number of workers allocated when a project is created is the "project worker allocation." While this allocation stays with the project if it is shared, any user participating on the project is still restricted to their personal worker allocation.

For example, a project owner may have 12 personal workers allocated to a project and share it with a user who has a four-worker personal allocation. The person invited to the project is still limited by their personal allocation, even if the project reflects a higher worker count.

### Change worker allocation {: #change-worker-allocation }

The workers used during EDA1 (EDA workers) are set and controlled by the system; neither the admin or user can increase allocation of these workers. Increasing the displayed workers count during EDA does not affect how quickly data is analyzed or processed during this phase.

During model development (EDA2), a user can increase the workers count as long as there are workers available to that user (based on personal worker allocation). Adjusting the worker toggle in the worker usage panel causes more workers to participate in processing. Users can read full details about [the Worker Queue](worker-queue) for a better understanding of how it works.

![](images/admin-worker-toggle1.png)

!!! note
    If the user's personal worker allocation is changed (increased or decreased), existing projects are not affected.

### Monitor and manage worker counts (Self-Managed only) {: #monitor-and-manage-worker-counts-self-managed-only }

For admins, the [**Resource Monitor**](resource-monitor) provides a dashboard showing modeling worker use across the cluster. This helps to monitor worker usage, ensure that workers are being shared as needed between DataRobot users, and determine when to make changes to a user's worker counts. To prevent resource contention and restrict worker access, the admin can add users to [organizations](manage-orgs).

### Change personal worker allocation {: #change-personal-worker-allocation }

Admins can set the maximum number of workers each user can allocate to their project.

1. Expand the profile icon located in the upper right and click **APP ADMIN > Users** from the dropdown menu.

    ![](images/admin-create-user-2.png)

2. Locate and select the user to open their profile page.
3. Click **Permissions** and scroll down to **Modeling workers limit**.

    ![](images/admin-personal-worker-1.png)

4. Enter the worker limit in the field and click **Save changes**.

    ![](images/admin-worker-limit.png)



## What are groups? {: #what-are-groups }

You can create groups as a way to manage users, control project sharing, apply actions across user populations, and more. A user can be a member of up to ten groups, or not a member of any group. A group can be associated with a single organization, and a single organization can be the "parent organization" for multiple groups. Project owners can share their projects with a group; this makes the project accessible to all members of that group.

Essentially, groups are a container of users that you can take bulk actions on. For example, if you share a project with a group, all users in the group can see the project (and work with it depending on the permission granted when sharing). Or, you can apply bulk permissions so that all users in a group have a permission set.

See the section on [creating groups](manage-groups) for information on setting up groups in your installation.

## What are organizations? {: #what-are-organizations }

To ensure workers are available as needed and prevent resource contention, an admin can add users to organizations. Organizations provide a way to help administrators manage DataRobot users and [groups](#what-are-groups?).

=== "SaaS"

	* You can use organizations to control [worker allocation](#modeling-worker-allocation) for groups of users to restrict the total number of workers available to all members of the organization.
	* Project owners can share their projects with an organization; this makes the project accessible to all members of that organization.
	* All users are required to belong to one and only one organization.

	Most commonly, organizations are used to set a cap on the total number of shared modeling workers the members of an organization can use in parallel. For example, you can create an organization of five users that has an allocation of ten workers. For this organization, the 5 users can collectively use up to 10 workers at one time, regardless of their personal worker allocations. *This is not a cascading allocation; each user in the organization does not receive that allocation, they all share it.*

	If a user with a personal allocation of 4 workers is defined in an organization with a worker allocation of 10 workers, the user can use no more than his personal allocation, i.e., 4 workers in this example. Organization membership is not a requirement for DataRobot users and users can be defined in only one organization at a time.

	The *system admin* manages the type of organization described above. Additionally there is a *Organization User Admin*, which is a user that has access to manage all users within their own organization and create groups for the organization. This type of admin does not have access to view other organizations or view users/groups outside of their organization.

=== "Self-Managed"

	* You can use organizations to control [worker allocation](#modeling-worker-allocation) for groups of users to restrict the total number of workers available to all members of the organization.
	* Project owners can share their projects with an organization; this makes the project accessible to all members of that organization.

	* You can create organizations configured with a "restricted sharing" setting. When set, organization members cannot share projects with users and groups outside of their organizations. There is one exception: members of a "restricted sharing" organization can share projects with users outside of the organization who have the admin setting "Enable support of restricted organizations." This is useful, for example, when a member needs to share a project with a customer support user who is outside of the organization.

	Most commonly, organizations are used to set a cap on the total number of shared modeling workers the members of an organization can use in parallel. For example, you can create an organization of five users that has an allocation of ten workers. For this organization, the 5 users can collectively use up to 10 workers at one time, regardless of their personal worker allocations. *This is not a cascading allocation; each user in the organization does not receive that allocation, they all share it.*

	If a user with a personal allocation of 4 workers is defined in an organization with a worker allocation of 10 workers, the user can use no more than his personal allocation, i.e., 4 workers in this example. Organization membership is not a requirement for DataRobot users and users can be defined in only one organization at a time.

	The *system admin* manages the type of organization described above. Additionally there is a *Organization User Admin*, which is a user that has access to manage all users within their own organization and create groups for the organization. This type of admin does not have access to view other organizations or view users/groups outside of their organization.

	See the section on [creating organizations](manage-orgs) for information on setting up organizations in your installation.
