User Roles & Access Controls

Freeplay offers a variety of user roles so you can ensure each person in your organization can do everything they need to do their job within the platform, but nothing more.

Roles

There are 4 primary roles in the Freeplay product.

Admin

Admins in Freeplay can perform any action, including inviting and managing other users and configuring models available to your team. Use the admin role for those who will be spearheading the adoption of Freeplay within your organization. We recommend having at least 2-3 admins on your account, large organizations may benefit from having additional admins.

Editors

Editors can perform most actions in Freeplay but are primarily restricted from taking actions which could have major impacts on the overall account, particularly as it relates to compliance and user management. Use this role for those who are contributing heavily to day to day development.

Editors are restricted from the following actions:

• Inviting other users
• Managing other users
• Configuring account-level LLM providers and models
• Setting account-level spend limits

Analysts

Analysts inherit the restrictions of Editors but are additionally prohibited from performing sensitive actions like prompt & model deployment or data deletion. Use this role for those who will be reviewing data, running experiments, and evaluating data, but who won't be actively pushing changes to a production system.

In addition to the aforementioned restrictions of Editors, Analysts are also restricted from the following actions:

• Deploying prompt templates
• Deleting prompt templates
• Deleting production data
• Deleting dataset examples
• Managing API keys (create or delete)
• Managing environments (create of delete)
• Configuring models

Guests

Guests have the same permissions as Analysts, except that they can only see data for the specific projects they are invited to. (Unlike Analysts who have account-level/site-wide permissions to access any shared projects.) This role is intended for contractors or other collaborators with a narrow scope of focus.

Role Enforcement & Project-Level Permissions

Each user will be given a role at the account level. This is will determine what the user can and can't do by default in any project (i.e. site-wide, default permissions).

However, a user's role can be changed within the context of a specific project. For example, an account level Analyst can be given an Editor role on a specific project. The user will have all the permission associated with an Editor in that specific project, but will maintain their Analyst role at the account level and across other projects.

Private vs. Public Projects

There are two levels of accessibility for projects. Project privacy is determined at creation, but can also be changed after creation. To change this setting on a project, go to Edit Project > Project access and select either "Anyone at your organization" or "🔒 Only specific members".

Public Projects

Public projects can be accessed by all users on the account with their default user roles. Users do not need to be specifically granted access to the project in order to access it (except Guests, who must be added). We recommend using this project type for any projects that do not contain sensitive data.

Private Projects

Private projects can only be accessed by users who have been directly granted access to the project. Each private projects will have 1 or more project admin who determine access for the project. We recommend using this project type for any projects that contain data that only a subset of internal employees or contractors are authorized to see.