To provide your end users with access, you need to provision them by creating both a user account and an organization. Although the admin UI lets you create new users and organizations, API is the best method to provision new users because it lets you automate the process and also lets you define the license of new organizations. You can use these API endpoints in scenarios to provision new users. For instance, the contracting event in a CRM app can trigger your scenario to create an organization and user on your instance.

The following are the main tasks required for provisioning new users:

• Create the user if they do not already exist on your instance. Create the user first so you can later assign them to organizations and teams with appropriate roles. The best practice is to create the user and send an invitation without defining their password.

• Create an organization for the customer. You need to define the license of each new organization on your instance. The license includes many parameters that allow you to control access to features and limit usage. If not otherwise defined, all new organizations inherit your instance's default license.

You can automate the above tasks via Make scenarios you create to suit your specific needs. Remember that you can integrate provisioning tasks with your customer onboarding.

Although you can add users and create organizations in the Administration interface, using API lets you automate your provisioning. You can create Make scenarios using the and to perform these tasks. The above API endpoints let you perform all necessary provisioning tasks for new users.

After provisioning new end users, you can do the following:

• Perform maintenance tasks, such as resetting passwords. Use the administrative API endpoints for these tasks.

• Enable special options designed for app developers on your instance. These options allow users to create, test, and publish custom apps.

Make White Label administrators rely on the following principles to manage end users:

• A customer is an organization - Make's organizations provide a structure that lets you grant only the access that you want to share with each end customer. Assigning each end customer to an organization lets you use the following to customize access:

  • License parameter - each organization has an independent license that contains definable parameters. The license parameters let you assign a custom set of limits, features, and access for each end customer.

  • Permission roles - every user has defined roles for the instance, organization, and team level. Making each end customer the owner of an organization lets you use their license parameter and role to control their access to your platform's resources and data. Assigning end customers to organizations also isolates your end customers from each other.

• Every organization has only one owner - although an organization can have multiple administrators, only one user can be the owner. Again, the standard practice is to designate the owner of the account as the organization owner. This arrangement gives your customer the most authority over their own organization and allows them to invite users to their organization and assign organization roles to their organization members.

• Any user can belong to multiple organizations - end users do not need to own an organization to have access to it. If you allow it in their license, end customers can invite new end users to their organization. For example, in a B2B SaaS use case, a company is your customer. They may have several organizations and multiple users on your instance to automate and collaborate.

The following tasks represent the customer/user life cycle. Use the links to access more detailed information:

1. - You need to add every new user to the platform and create an organization for them. Although the SSO options let you do this automatically, creating your own automation and using admin API endpoints is a better method. The admin API endpoints provide more possibilities including defining the license to limit the new customer's access. The admin API also lets you assign roles to further define the new customer's access to your platform.

2. - Administrative tasks such as resetting passwords and enabling features for your internal app developers.

3. of customers.

When you need to deprovision a customer from your instance, using Make API allows you to automate the process and offers more functionality than the Administration interface. The recommended procedure is to set all consumables to 0 and give the customer limited access to the organization. This way preserves their scenarios and data in the event that the customer decides to subscribe again.

1. Use the license object to set operations and other consumables to 0 or the minimum value. This configuration freezes the organization and its scenarios while allowing former customers to have access to their data stores and other assets associated with their organization.

2. Transfer organization ownership to a dummy owner that you create. Reassign the end user to a role with limited access, such as member. This step limits the former customer's permission privileges while preserving their data and other assets for later use if the customer returns.

You can verify the deprovisioned user's access by using the Login as user feature on

Every user has a distinct role that defines their access to your platform. Make White label offers three levels of access control:

1. Instance level - These roles define access to the administration interface as well as specific permissions. There are roles for administrative, app development, and support purposes. See the reference tables of instance-level roles for more details.

2. Organization level - Roles for organizations define access to:

   1. Assets, such as scenarios and data stores associated with the organization.

   2. Abilities, such as managing organization members.

3. Team level - The lowest level of access management. Roles for teams define access to:

   • Assets, such as scenarios and data stores associated with the team.

   • Abilities, such as managing team members.

You can assign roles by the or by API. Users with the SA role can .

Every organization has a license which is a collection of parameters that define access to features, such as custom variables, and limit consumables and assets, such as operations and data stores. You can use these parameters to do the following:

• Offer multiple tiers of access. For example, offering your customers more operations or data stores based on their contracts.

• Control resource usage on your instance. For example, limits on API calls or time between scenario runs.

The Apps and Features tab of the user detail page offers options useful for users developing custom apps on your platform.

Can create Apps without ID suffix

When a user creates a custom app, there is an automatically generated internal name for the app. By default, that automatically assigned name includes a random string suffix. Native apps developed by Make do not have this suffix. The ID suffix allows the Make apps team and end users to create apps for the same third-party app. Allowing your end users to create apps without the ID suffix might create conflicts that prevent you from installing native apps. For example, if you create your own custom app for Google Sheets with a suffix ID, you cannot install Make's native app for Google Sheets because of conflicting names.

Can use custom IML functions in Apps

IML is . Enabling this option lets the user create custom functions using IML.

Can commit changes to approved Apps

Once you publish and compile an app on your instance, changes to that custom app risk breaking scenarios. This option lets a user commit changes to an app previously approved and compiled. See our for more details on the risks involved.

Can see hidden modules

After you approve and compile an app, that app receives a private tag. This means that users cannot see or access the app until you publish the app. Enabling this option lets the user see and access the private app and its modules.

Allow access to internal IP addresses from scenarios

Only applicable for on-premises instances. Enabling allows the enabled user to create scenarios that access your local network via your internal IP addresses. Enabling this option might compromise your network security.