Define Organization Behavior

Learn to define organization behavior within applications for Auth0’s Organizations feature.

When representing your application in Auth0, you can specify what types of users the application should support. Some applications support individuals logging in with personal accounts, while others are intended for use by members of organizations. Some should support both. This is known as organization behavior and can be set for each application that you connect to Auth0.

For example, your application could have:

• A generic marketing landing page that has a Log in button that takes your users to the Auth0 login flow without an Organization.
• A separate URL for each of your B2B customers (e.g., Acme users go to acme.yourcompany.com) that redirects users to Auth0 with an Organization, so that your users see Acme’s SSO Login button.

You can define Organization behavior to allow either of these scenarios. Additionally, you can configure Organization behavior such that if your application requires that an Organization be provided but your user accidentally is sent to Auth0 without an organization, they would see a prompt that would allow them to enter the name of their organization.

You can define organization behavior using either the Auth0 Dashboard or the Management API.

Auth0 Dashboard

To define organization behavior via the Auth0 Dashboard:

1. Navigate to Auth0 Dashboard > Applications, and select the application for which you want to configure organizations.
2. Switch to the Login Experience view and configure the appropriate settings:

Field	Description	API Mapping
Type of Users	Determines which category of users can log in to your application. Options include: Individuals: Users can sign up with a personal account and log directly in to your application. Individual users cannot log in using an Organization. Business Users: Users must be a member of an Organization in order to log in. When selected, you must either provide an Organization when you redirect users to the /authorize endpoint or set your Login Flow to Prompt for Organization. Both: Users can log in as an Organization member or sign up with a personal account.	Type of Users maps to organization_usage Options: Individuals maps to deny Business Users maps to require Both maps to allow
Login Flow	Determines the initial login prompt presented to users when they access your application. You can only configure this field if Type of Users is set to Businsess Users or Both. Options include: Prompt for Credentials: Users are first asked to provide their login credentials. After logging in, users can select their Organization. Prompt for Organization: Users are first asked to select their Organization. Then, they can provide their credentials to log in. No Prompt: Auth0 does not dictate which login prompt is given to users. Instead, your application is responsible for sending the required parameters to Auth0 to display the appropriate prompt.	Login Flow maps to organization_require_behavior Options: Prompt for Credentials maps to post_login_prompt Prompt for Organization maps to pre_login_prompt No Prompt maps to no_prompt
Organization Discovery	Defines the method used to identify the user’s organization before authentication. Only available with Prompt for Organization Login Flow. Options include: Prompt for Organization Email: Users are first asked to provide their email address associated with their Organization. Prompt for Organization Name: Users are first asked to provide the name of their Organization. Prompt for Organization Email and Name: Users are first asked to provide the name of their Organization or email associated with their Organization.	Prompt for Emails: maps to email. Prompt for Organization: maps to organization_name. Prompt for Organization Email and Name: maps to email and organization_name.

3. Select Save changes.

Management API

Make a PATCH call to the Update a Client endpoint. Be sure to replace client_id, mgmt_api_access_token, organization_usage, and organization_require_behavior placeholder values with your client ID, Management API Access Token, organization use option, and organization behavior option, respectively.

Value	Description
CLIENT_ID	ID of the application for which you want to add organization behavior.
MGMT_API_ACCESS_TOKEN	Access Tokens for the Management API with the scope update:clients.
ORGANIZATION_USAGE	Dictates whether your application can support users logging into an organization. Options include: deny: (Default) Users cannot log in using an organization. allow: Users can log in with or without an Organization. When selected, you must provide an organization when you redirect users to the /authorize endpoint. require: Users must log in using an organization. When selected, you must either provide an organization when you redirect users to the /authorize endpoint or set organization_require_behavior to pre_login_prompt to allow users to choose an organization before they log in.
ORGANIZATION_REQUIRE_BEHAVIOR	Determines the Login Flow presented to users accessing your application. Only applicable when organization_usage is set to require or allow. Options include: no_prompt: (Default) Display no prompt. Requests without a valid organization parameter are rejected. pre_login_prompt: Prompt users to select an Organization before they can log in. You can only use this option if organization_usage is set to require. post_login_prompt: Prompt users to log in with their credentials. After they log in, prompt users to select their Organization.
ORGANIZATION_DISCOVERY_METHODS	Determines the method to identify a user’s organization before authentication. Only applicable when organization_require_behavior is pre_login_prompt and organization_usage is set to require or allow. email: (Default) Users are prompted to enter their email address associated with their Organization. organization_name: Users are prompted to enter the name associated with their Organization. Organization name and email: Users are prompted for the email address or name associated with their Organization.

Response status codes

Possible response status codes are as follows:

Status code	Error code	Message	Cause
200		Client successfully updated.
400	invalid_uri	Invalid request URI. The message will vary depending on the cause.	The path is not valid.
400	invalid_body	Invalid request body. The message will vary depending on the cause.	The request payload is not valid.
401		Invalid token.
401		Client is not global.
401		Invalid signature received for JSON Web Token validation.
403	insufficient_scope	Insufficient scope; expected any of: update:clients.	Tried to read/write a field that is not allowed with provided bearer token scopes.
403	insufficient_scope	Some fields cannot be updated with the permissions granted by the bearer token scopes. The message will vary depending on the fields and the scopes.	Tried to read/write a field that is not allowed with provided bearer token scopes.
403	operation_not_supported	The account is not allowed to perform this operation.	The account is not allowed to perform this operation.
404	inexistent_client	Client not found.	Inexistent resource. Specified application does not exist.
429		Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.