Stay up-to-date with monthly release notes including the latest improvements, new features, fixes, and updates that are available for White Label instances and their public-facing customers. Here's also where you'll find information on current version numbers for services and software running in Make's release environment.

Using a link lets you use your custom app only in those organizations you want. You need to manually add the app to each organization.

1. Go to My apps and click on the app you want to share.

2. Click Publish.

3. Click Share a public link.

4. Open the link and click Install in the new window tab.

5. Select the organizations you want the app to be visible on and click Install.

To change the timeout of a custom app:

1. Go to the Apps page and click Detail for the app you want to edit.

2. Go to the Base tab.

3. Add or change the timeout in the app's Common data field by entering the following parameter with time in milliseconds: {"timeout":300000}

4. Click the save icon.

The page validates and saves your updated timeout. You can view this information in the Common data field.

The following tools are necessary for scenario execution on your instance:

1. Flow control

2. Tools

3. Text parser

4. App runtime

These tools come preinstalled on your instance. They appear on the Native Apps page because they share similarities with apps. For example, the preinstalled tools are available as modules in scenarios.

You can bypass SSO by going to https://xyz.onmake.com/admin/login and entering your credentials. Using the /admin/login page lets you return to the System settings page and adjust your configuration.

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’s White Label Help Center is an OEM customer’s guide to managing and administrating their white-labeled instance of Make. This documentation will walk you through administrative tasks you can perform, from rebranding the appearance of your instance to managing user access roles.

Manage your Make White Label instance

Once your White Label instance has been implemented by Make and you’re ready to start managing it, you can do so in the following ways:

Native apps are those apps that Make develops and publishes. To grant you greater control over what is available to your customers, Make does not install these apps on your instance. You must install and configure native apps for your end-users to access and use in scenarios.

Once installed, you can customize which modules are available for your users.

1. Click Administration.

2. Click Native apps. Apps already installed appear at the top of the list.

You can allow your users to create custom apps by enabling the Apps platform option in Administration > System Settings. In the apps platform, your users can create apps that connect to third-party services not included in the apps developed and released by Make. The primary requirement is that the third party has an API. Refer to our public documentation for details on how to create a custom app.

Administrators can supervise custom app development and manage access to custom apps. Access to custom apps and their visibility to users varies according to the development stage. Each stage of custom app development corresponds to a status you can check by going to Administration > Apps. The following chart describes who can use a custom app in scenarios and how they access the custom app:

This section provides a summary of how to offer custom apps that you or your users. For more information, see our article on .

You and end-users can create custom apps and modules for 3rd party services not available from the native apps catalog. By default, custom apps are only available to the user who created them.

Make lets you share private custom apps in two ways:

1. Using a link to share a custom app. This option lets you restrict access to your custom app. Only users with a link to this app can use its modules in their scenarios.

2. Compiling the app into your instance for all organizations and users. This option makes the app available to all users on your Make White Label instance.

A shared webhook sends event data from the app to a single URL for each Make instance. Make then forwards the payload to the webhook in the scenario based on the metadata in the payload. For example, the Slack app uses shared webhooks. Make uses shared webhooks rarely, only in case there is no other implementation option.

To configure apps that use a shared webhook, use the shared webhook URL for the app and its specific version.

The following is the general process for finding the shared webhook URL for the app:

1. Go to Administration > Native Apps.

2. Click the app you want to set up.

Once you have your Client ID and Client secret from Google, you need to enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps and click the Google app you want to configure

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

The Client ID and Client Secret appear in JSON format in the

You can configure single sign-on (SSO) from the System settings page and from your Identity Provider (IdP). Make White Label's SSO options let you decide whether to create a new organization for new end-users or not. This provisioning lets your end-users sign in and automatically receive their own organization for billing purposes.

Your instance supports the following authentication standards:

• OpenID Connect (OIDC) (OAuth 2.0-based)

• SAML 2.0

Click any of the following for configuration information:

You can uninstall an app from your Make White Label instance at any time from the Native apps page. The following procedure also works for custom apps you have compiled. If you attempt to uninstall an app used in scenarios, you receive a warning message.

1. Go to Administration > Native apps.

2. Find the app you want to uninstall on the list and click Uninstall.

3. Click Really?.

To change the timeout of a native app:

1. Open the app on the Native apps page.

2. Go to the relevant app version.

3. Change the timeout in the app's Common data by entering the following parameter with time in milliseconds: {"timeout":300000}

As an instance administrator, you can intervene during scenario execution by going to a scenario's execution log. Use the Admin button's Unlock execution option to interrupt and stop a locked execution. Unlocking an execution allows the scenario to process the next bundle.

1. Go to Administration > Recent executions.

2. Find the scenario execution you want to access and click Details.

3. Click Admin.

Before configuring SSO, you need to assign a namespace and create a service provider certificate and private key. These important steps provide information you need to enter later.

Create your namespace:

1. Go to Administration > System settings.

2. Scroll down to SSO Type.

3. Under SSO type, select

Your Make private instance has the following groups of instance-level permission roles:

• System roles designed for the needs of administering the instance.

• Developer roles designed for users who edit and create custom applications.

• Support roles designed for those who provide customer support.

The following charts provide the details of which specific permissions are enabled for each role.

The recent executions page serves as an execution log for your entire instance which lists the most recent scenario execution first.

Although the Recent executions page does not identify the scenario, organization, or user, you can see information such as execution status, duration, operations consumed, and amount of data transferred. The recent executions page also lets you perform the following tasks:

• Search scenario executions by the date and time the scenario execution started.

• Search scenario executions by execution status.

To create OAuth 2.0 credentials for Clickup, follow these steps:

1. Log into ClickUp.

2. Click on your avatar in the lower-left corner and click Integrations.

3. Click ClickUp API.

Once you have your Client ID and Client secret from the Asana developers portal, you can enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps and click Asana.

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

You can log out a user via the user detail page. Deleting the session logs out that user and they must log in again.

1. Go to Administration > Users.

2. Click Detail next to the user whose session you want to access.

3. Click Sessions.

The System settings page lets you enable login features to enhance the security and integration of your Make White Label instance. The single sign-on (SSO) configuration supports a wide range of identity providers. You can also enable end-users to set up two-factor authentication for their accounts.

Your Make White Label instance supports the following login options:

• Default email and password login page

• Single sign-on (SSO)

The method for restricting access to a custom app depends on its development stage:

• Private - Once a user has created a custom app, they can use it in scenarios. The only way to restrict access is to disable the apps platform from Administration > System settings before users create custom apps. It is possible to delete an app but only when it is private. Once published, it is no longer possible to delete an app.

• Public - Once published, a custom app is visible and accessible to all users in the creator's organization. You can prevent users outside of the organization from installing the app by setting the installPublicApps to false.

To create OAuth 2.0 credentials for Asana:

1. Log in to your Asana developers account.

2. Under My apps, click Create new app.

3. In the Create new app window, enter a name for your OAuth app and select any of the use cases for your app. Click Create app.

Once you have your Client ID and Client secret from the Azure portal, you need to enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps and click the Microsoft app you want to configure.

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

The Client ID and Client Secret appear in JSON format in the

The administrative scenarios page lists all scenarios on your instance starting with the most recently created scenario. From Administrative > Scenarios you can access scenario diagrams and execution logs to monitor the following:

• Scenario operation consumption

• Data transfer usage

• Scenario execution history

The Make White label administration UI lets you access a page similar to the user-side organization page. Here you can find an organization's operation consumption, data transfer, and storage usage in a graph similar to that seen on the user side.

1. Go to Administration > Organizations.

2. Use the filter button to search by one or more of the following:

   • Organization ID number

Once you have your Client ID and Client secret from the Meta for Developers portal, you need to enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps and click the Meta app you want to configure.

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

Compiling an app installs your custom app on a global level for all users and organizations. Once compiled, you can install and manage the custom app the same way as a native app.

1. Go to My apps and click on the app you want to share.

2. Click Publish.

3. Click Request approval.

4. Go to Administration > Apps . Find your app submitted for review and click Detail. The app setup page opens.

5. Click Approve to compile the app.

6. A dialog pops up. Enter an internal system name for the app or use the one autogenerated for you. Click Save.

The compiled app now appears on the Native apps page. You can install it the same way as any other native app.

In some cases, such as transferring large files, you need to adjust the app timeout limit. The longest possible timeout period is 5 minutes or 300,000 milliseconds. The procedure for changing the timeout depends on whether you need to adjust a native or custom app.

Facebook, Google, and other apps require an OAuth 2.0 connection. In these cases, you need OAuth 2.0 credentials from that third party. For example, Google requires you to create an app on the Google developers console.

Entering your credentials on your Make White Label instance creates a connection that enables users to use that app's modules in their scenarios and access their data. For example, entering Facebook OAuth credentials allows users to connect their Facebook account to Facebook modules in their scenarios. In these cases, the credentials you enter for an app on the Native apps page create a 'parent connection' that enables users to create their 'child connections'.

The following procedure creates an OAuth 2.0 connection accessible to all users on your instance. This configuration gives your end-users access to the third-party app via the credentials you enter and save at Administration > Native apps > {App} > Connection. End-users must still grant permission. For example, Google asks end-users to grant permission and allow access to their Google account. End-users need only their account credentials to grant permissions.

1. Go to Admin > Native Apps and click the third-party app you want to configure.

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

The Client ID and Client Secret appear in JSON format in the Common data field.

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 HTTP and Make modules to perform these tasks. The above API endpoints let you perform all necessary provisioning tasks for new users.

Once you have your Client ID and Client secret from the Discord developers portal, you need to enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps > Discord > Connection: Discord.

2. Under Client ID and Client Secret enter your credentials from step 4.

3. Under Bot Token, enter the token copied in step 8.

4. Click Save.

The Client ID, Client Secret, and Bot Token appear in JSON format in the Common data field.

Once you configure SSO, your end-users don't use the default sign-in form. Instead, they use the dedicated SSO sign-in options.

1. Go to your login URL.

2. Click Sign in with SSO.

3. Log in using your identity provider and consent to Make's access to your user data.

The user is now logged in. If the user was not assigned to your organization before, the system creates a new users account for them and assigns them to the selected default team.

1. Go to Administration > Recent executions.

2. Click the filter image next to Started or Status and enter or select your search criteria.

   • Started You can define the time/date Since and/or Until to narrow your results.

   • Status lets you search by scenario execution status:

     • All

     • Success

     • Warning

     • Error

3. Hit Enter.

The page only lists those scenarios matching your search criteria.

The recent executions page's Detail button lets you access that scenario's log entry for that execution. Clicking Detail redirects you to a page that is similar to the execution log of the public cloud but has additional administration functionality:

1. Go to Administration > Recent executions.

2. Find the scenario execution you want to access.

3. Click Detail next to that scenario.

A redirect takes you to a scenario execution details page where you can see the scenario diagram and execution information.

1. Go to the login page for your instance. Log out if needed.

2. Click Sign in with SSO.

3. Log in using your Okta credentials and consent to Make's access to your user data.

1. Go to Administration > Scenarios.

2. Click the filter image next to any of the following columns to search for a specific scenario:

   • # - Sort by unique ID number. Typically this represents the order scenarios are created on your instance.

   • Name - Name assigned to a scenario.

   • Used packages - Apps used within a scenario. Although the package is often the same as the app name, this is not always true. For example, a webhook is gateway. You can hover over an app's icon to find the package name.

   • Status - Inactive, Active, or Deleted.

3. Click Details.

Make redirects to a page similar to the user-side scenario page.

The following manual configuration creates a SAML SSO configuration for your Enterprise organization.

Prerequisites

• Owner or admin role in an Enterprise organization

• Service provider certificate and private key that you create

Supported features

This configuration supports the following:

• Service provider initiated SSO

• Single Log Out [optional]

When an app offers multiple versions, there's a tab for each version where you can change the visibility of that version's modules.

Go to Native apps and make as many versions as you want visible by following step 4 of the preceding process.

If you do not want to share your OAuth 2.0 connection, you can leave the credential fields blank. Leaving those fields blank requires end-users to enter their own OAuth 2.0 credentials in the Scenario editor.

You must then provide end-users with a redirect URI because your end-users need that redirect URI in order to create their own Client ID and Client secret. Make's public help center has information on how end-users can do this themselves.

1. Go to Organization > SSO.

2. Enter the following information from Okta into the IdP login URL and Identity provider certificate fields.

{"email":"{{get(user.attributes.email, 1)}}","name":"{{get(user.attributes.profileFirstName, 1)}}
{{get(user.attributes.profileLastName, 1)}}","id":"{{user.name_id}}"}

1. In the Allow unencrypted assertions, select Yes.

2. In the Allow unsigned responses, select No.

3. To allow the Sign requests, select Yes.

4. Click Save.

To configure Asana on your instance, you need to create OAuth 2.0 credentials in the Asana developers portal and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets Asana share data with the modules in scenarios.

To avoid a known issue, follow steps 6 and 7 of the page Steps in Asana.

Prerequisites

• An Asana developers account

• Access to the Administration UI of your Make instance

Required information

• Your

To configure Google apps on your instance, you need to create OAuth 2.0 credentials in the Google Developer Console and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets Google share data with the modules in scenarios.

Prerequisites

• A Google Developer Console account

• Access to the Administration UI of your instance

• - for your users's scenarios to work with Google apps, Google requires a verification process.

Required information

• Your

Make's administration interface lets you install, manage, and control access to apps on your instance. In order for your end-users to access apps in their scenarios, you must first install and configure them on your instance. Your instance has only several essential tools preinstalled by default. These preinstalled tools are necessary for all scenarios to execute and include important modules like routers, iterators, and aggregators. You need to install and configure any other app you want to provide on your instance.

Managing apps requires an instance-level role such as SA or Admin. Make organizes apps into two main groups, each with its own page in the admin interface:

• Native Apps - The complete catalog of apps that Make develops and publishes, including enterprise and premium apps. The Native apps page lets you:

• Custom Apps - Private apps that you or your end-users create. You can share access to custom apps in the following ways:

You can bypass SSO by going to https://xyz.onmake.com/admin/login and entering your credentials. Using the /admin/login page lets you return to the System settings page and adjust your configuration.

• Recent scenario executions

• Recently created scenarios

• Users' recent sessions

One advantage of event monitoring via the administration interface is that you can then access further details or take action in the same UI. By default, most instance admin roles include access to the above for purposes of customer support, development, and general administration.

Microsoft Azure supports both OAuth 2.0 and SAML 2. Perform the following steps to connect Make with Azure Active Directory.

OAuth 2.0

1. Log in to your Azure Portal and open Azure Active Directory.

2. Open App registrations and click New registration.

3. Give the registration a name.

4. Fill in the Redirect URL.

   • Find the Redirect URL In Make > Organization > Settings after you select an SSO type.

5. Click Register.

6. Note down the Application (client) ID.

   • Paste this ID into your Make settings.

7. Go to Certificates and secrets and click New client secret.

   • Paste the secret value into your Make settings.

8. Go to Overview and click Endpoints.

   • Paste the OAuth 2.0 authorization endpoint (v2) into the Authorize URL field in Make settings.

   • Paste the OAuth 2.0 token endpoint (v2) into the Token URL field in Make settings.

9. Paste the following into the User information URL in Make settings.

10. In Make, set up Login scopes and Scopes separator:

    • Login scopes: openid, profile, email

    • Scopes separator: space

11. In Make, paste the following into User information IML resolve. This tells Make how to map user information received from Azure to information in Make database.

    • {"id":"{{id}}","email":"{{mail}}"}

To configure Microsoft apps on your instance, you need to create OAuth 2.0 credentials in the Azure AD portal and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets Microsoft share data with the modules in scenarios.

Prerequisites

• Administrative privileges in the Microsoft Azure AD portal.

• Administrative access to your Make instance.

• - for your users's scenarios to work with Microsoft apps, Microsoft requires a verification process.

Required information

• Your

To configure ClickUp on your instance, you need to create OAuth 2.0 credentials in the [app developers portal w/ link] and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets ClickUp share data with the modules in scenarios.

Prerequisites

• A ClickUp account

• Access to the Administration UI of your Make instance

Required information

• Your

The Recent executions page displays the following information in columns:

Make White Label supports two-factor authentication (2FA), such as Google's Authenticator app. The following procedure enables 2FA for your instance. End-users must complete the process by going to their profiles and using Google Authenticator or a similar app.

1. Go to Administration > System Settings.

2. Select Enabled from the Two Factor Authentication menu.

3. For Two Factor Authentication app name (visible in Google Authenticator) enter the name you want to appear in the authentication app.

Your instance now allows end-users to set up 2FA. Verify by clicking Leave administration and going to Profile > 2FA. When a user sets up 2FA, a window opens with the QR code for Google Authenticator or similar apps. Scan the QR code and enter the numeric code in the field.

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 .

Make White Label lets you designate tier levels for apps. Tiers limit access to apps so that only specific end-users can use those apps in their scenarios. For example, Make uses tiers to offer a premium level of apps reserved for Enterprise customers.

You can assign app tier levels by entering an integer between 0 and 3 in an app's configuration page. 0 means that the app is available to all organizations. 3 indicates the highest premium tier. Each tier level includes all apps from lower tiers. For example, tier 2 includes tier levels 0, 1, and 2.

You can then define an organization's access to premium tiers via the organization's .

1. Go to Administration > Native Apps > {app}.

2. Under Premium app, use the arrows to assign an integer from 0 to 3 inclusive.

3. A confirmation message briefly appears. You can now use the premiumApps parameter of the license object to control access.

To configure Discord modules on your instance, you need to create OAuth 2.0 credentials in the Discord developers portal and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets Discord share data with the modules in scenarios.

Prerequisites

• A Discord developers account

• Access to the Administration UI of your instance

Required information

To configure Facebook, Instagram, and WhatsApp apps on your instance, you need to create OAuth 2.0 credentials in the Meta for Developers Console and enter them in the Native Apps page of your instance. This OAuth 2.0 connection lets Meta share data with the modules in scenarios.

Prerequisites

• A Meta for Developers account

  • Best practice is to use the account connected with your business.

• Access to the Administration UI of your instance

• - for your users's scenarios to work with Meta apps, Meta requires a verification process.

Required information

• Your

• The URL of your privacy policy

Some apps require an OAuth 2.0 connection to function on your instance. For example, Slack and Google Sheets need OAuth 2.0 credentials to access the relevant APIs. OAuth 2.0 configuration requires the following:

• A Client ID and Client Secret from the third-party app you want on your instance. In most cases, you need a developer account with the third party to get the required credentials.

• A redirect URI. You can find the appropriate redirect URI at Administration > Native apps > {app} > Connection in the Account parameters section. The general pattern for redirect URIs is: https://{yoursubdomain}.integromat.celonis.com/oauth/cb/{app_name}

To connect to Discord, you need to create a developer account to obtain the bot token, client ID, and client secret values by creating a custom application from your Discord developer account.

1. Log in to the .

2. Click Create New Application, enter a name for the application, and click Create.

3. On the left menu, click OAuth2, add the redirect URI for your instance, and click Save Changes.

For security and privacy reasons, some third parties require a rigorous verification process to demonstrate that your business has a legitimate use case. Make tries to support customers as much as possible in this process. That said, many of the requirements are beyond the scope of Make's control. In general, the verification process may involve the following:

• Rejection

  • Sometimes third-party feedback provides the specific required changes. Sometimes waiting several months and reapplying is successful. In general, you might be at the whims of the individual reviewing your verification.

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.

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.

Once you have your Client ID and Client secret from the app developers portal, you can enter them in the app's configuration on your instance.

1. Go to Admin > Native Apps and click Clickup.

2. Go to the Connection tab and enter your Client ID and Client secret.

3. Click Save.

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:

• 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 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.

The following sections describe the main stages of app visibility and the related administrative procedures.

Private app

All custom apps begin as a private app. Only instance-level admins and the user who creates the app can access it in the apps platform and develop the app.

Private apps can be shared within an organization by . An instance-level admin can install the app to an organization by logging in as a user:

1. Go to Administration > Users.

2. Find the user who created the app and click Detail.

3. In the upper right, click Login as user.

4. Once logged in as the user, create a scenario using any module from the private app.

5. Save the scenario.

6. In the popup, confirm the installation of the private app in the organization.

Once installed, all organization members can use the custom app's modules in their scenarios.

Public app

A public app is a custom app that the creating user has published. Like an installed private app, it appears for all organization users when they build scenarios. The difference is that the creating user has a link to share the app with any user on your instance. They share this link by copy-pasting it into an email or messenger app. The link recipient then installs the app on their organization.

Instance administrators can publish a custom app by the following procedure:

1. Go to Administration > Apps.

2. Find the custom app you want to publish and click Detail.

3. In the upper-right corner, click Publish.

You can use the license parameter installPublicApps to control whether an organization can install an app developed in an external organization:

• true to permit installation

• false to deny installation Default value

Approved app

Approving an app releases the app to all users and organizations on your instance. The custom app becomes one of your native apps and breaking changes are possible. Because of the accessibility and risks involved, be sure to test an app before approving it. Make tests all fields of all modules in scenarios before releasing an app.

Approval flow

Once published, a user can submit their app for review and approval by clicking Request approval. The custom app then appears with a ✓ in the In review column of Administration > Apps.

To approve a custom app:

1. Go to Administration > Apps.

2. Find the custom app with a ✓ in the In review column and click Details.

3. In the upper-right corner, click Approve.

4. A popup appears prompting you to name the app. The name entered here is an internal identifier and does not appear in the user UI. Best practice is to delete any suffix. For example:

A small popup appears to confirm that the custom app was successfully compiled.

Beta

You can mark custom apps as beta to indicate this status to all users. A beta label appears behind the app's name in all contexts: scenario builder, apps platform, and admin UI.

1. Go to Administration > Apps.

2. Find the custom app you want to publish and click Detail.

3. In the upper-right corner, click Options.

4. Click Add beta label.

The label now appears after the app's name on the same page and all other contexts.

You can remove the beta label by following the above procedure and clicking Remove beta label in step 4.

Creating your credentials involves the following general steps:

1. Create a project on the Google Cloud Platform Console (optional)

2. Configure your User consent screen

3. Add scopes

Create a project on the Google Cloud Platform Console

This procedure is optional. If you already have an existing OAuth app, you can add your Make redirect URI and any necessary scopes.

1. Go to the Google Cloud Console Platform.

2. From the projects list, select a project or create a new one.

3. Click APIs & Services.

4. Click + Create credentials.

The page for setting up your consent screen appears. Use the information in the following section to complete configuration.

Configure your User consent screen

These options in the Google Developer Console let you customize the consent pop-up that your users will see when configuring a connection on your instance.

Add scopes

After configuring your consent screen, the next page asks you to add scopes.

In the Scopes for Google APIs section, enter the required scopes for the Google service you want to connect to Make by checking the corresponding box for each required scope.

Create your OAuth credentials

1. In the left menu, click Credentials.

2. In the Application type field, select Web application.

3. In the Name field, enter the name you want for your application.

4. You need a redirect URI for the

Over time, you or your users might need to make changes to or new versions of a custom app. The process varies depending on the publishing status. Private and public apps share the same process that can result in . Approved apps have a separate process and can only experience breaking changes when the changes are compiled.

A key difference between changes in private/public apps compared to approved apps is when and how changes take effect. Any changes to a private or public app apply immediately. As a result, breaking changes are more likely to occur. Proceed with caution when changing a private or public app's code. See the for details.

Changes to an approved app require administrative approval before taking effect for instance users. Besides minimizing risk to your instance, there is another advantage. The user who created and developed the custom app has access to a private version of their app after an administrator approves the app. This user is able to make changes and test them using this private version before requesting admin approval.

When there are significant changes to the existing API or new API version, it may be best to create a new version of the app. When deciding whether to update the current app or create a new app version, take into account the user experience. Updating tens or hundreds of scenarios might be complicated and a time-consuming process. If possible, prioritize updating the current app instead of creating a new version.

Private/public apps

Changes and updates

In custom apps that haven't been approved, it is not possible to keep track of changes as there is no version control tool available.

If you need to keep track of changes and there is no plan to have the app approved, you can use the VS Code extension to export the current version of the app every time you make a change and store the files on GitHub or any similar tool.

Versioning

If you find out that a new API version has been implemented, or there have been major changes in the current API made, the best practice is to create a new app.

This way, everything stays consistent and there are no breaking changes made in the current app.

Approved apps

Changes and upates

Once you as an administrator approve an app, the code is locked and it starts to be versioned. When a new change is made in the code of the app, it automatically creates diff files, which contain detailed information about the changes. Every change made to the app is visible only to the user developing it unless an administrator commits the changes. Users developing apps can safely add and test new functions and when they are stable, they can have the changes checked by you and released on the instance level. Diff files are available in both environments, the web interface, and VS Code extension. Always make sure the changes will not break existing scenarios.

You can compile changes to an approved custom app:

1. Go to Administration > System settings and click Detail for the app you want to update.

2. Review the changes in the code by going to the Changes tab and clicking the icon for changes that appear there.

3. A redirect takes you to the relevant tab. In the yellow banner, click Show diff.

The changes appear in two columns that use red and green to highlight changes.

Versioning

Creating a new app version is best practice only in the following cases:

• There are major changes in the current API. For example, significant changes that impact the functionality of multiple modules.

• There is a new API version available. For example, a change from REST-style API to GraphQL-style.

• It is not possible to update the current app without .

Following these guidelines ensures a consistent user experience and that there are no breaking changes. If you decide to release a new version, users need to upgrade the modules in their scenarios using our .

To create your OAuth connection for Microsoft, complete these steps in the Azure portal:

1. Register your web application.

2. Create a client secret.

3. Grant the required permissions.

Register your web application.

When you create and register a web application in the Azure portal, Azure automatically creates your Client ID. This procedure only creates the web application. You still need to create your client secret and grant any required permissions.

1. Log in to your account.

2. Under Manage Azure Active Directory, click View.

3. In the left sidebar, click App registrations, and then click New registration.

4. Enter a name for your application.

Create a client secret

After registering your app, you can create a client secret in the Azure portal. Keep your client credentials in a safe place. If you lose your client secret, you can use this procedure to create a new one.

1. In the Azure AD B2C - App registrations page, click the application you created in the above procedure.

2. In the left sidebar, under Manage, click Certificates & secrets.

3. Click New client secret.

4. In the Description box, enter a description for the client secret.

Grant permissions

After registering a web application and getting your OAuth credentials, you need to grant the permissions required by Make apps. Refer to Connections and permission reference to find the .

1. Click App registrations.

2. Select the app you created in the above procedure and open its Overview page.

3. Under Manage, click API permissions.

4. Click + Add a permission.

You can verify success by checking the Status column. A green checkmark appears with the text Granted for {your Azure AD tenant name}.

To create OAuth 2.0 credentials for Facebook and other Meta apps, follow these general steps:

1. Create an app on the Meta for Developers portal.

2. Add products to get the permissions required by Make's Facebook apps.

3. Find your OAuth credentials.

Creating an App on the Meta for Developers Portal

Follow the . Use the following information to complete the procedure as documented by Meta:

1. Choose an app type: Select Business.

2. Choose a use case: Select Other.

Adding products

To access the required permissions, you add what Facebook calls products. Each product represents a unique set of API access. Facebook Login for Business enables access for most Make apps modules. Refer to the chart below for more details.

Facebook Login for Business

The default settings are compatible with your Make White Label instance and require no adjustments. However, you need to enter your OAuth redirect URI in the settings for Facebook login for business.

1. In the Meta for developers portal, go to the for your app.

2. In the left sidebar, click Add product.

3. Find Facebook login for business.

4. Under Client OAuth settings, enter your OAuth redirect URI in the field Valid OAuth Redirect URIs.

Refer to the table below and add any additional products required by Make's apps.

Finding your Client ID and secret

Adding Facebook login for business lets you begin using Facebook's API. You can now find your OAuth credentials and enter them in your instance.

1. In the Meta for developers portal, go to the App dashboard.

2. Click Settings.

3. Click Basic.

4. Find the App ID and copy paste it into the Client ID field on your Make instance at Administration > Native apps > {Facebook app} > Connection: Facebook

You can now test Facebook apps in scenarios. Without completing Meta's and you have limited API access to Facebook. As a result, some modules may encounter errors. The Testing and adding permissions section has information on gaining further Facebook API access.

Testing and adding permissions

You can request access to specific permissions by going to Meta for developers > App Dashboard > App Review > Permissions and Reviews. The Permissions and Reviews page lists permission and includes unsuccessful attempts from modules on your Make instance. Use this page to request access to specific permissions and find information about any further requirements.

The following chart contains the app alias, connection alias, and required for the most popular Google apps available as native apps. Once you enter OAuth 2.0 credentials for one app, for example, Google Sheets, that connection information automatically copies to another app with the same connection, for example, Google Docs. Once you configure a connection, Make reuses that connection for other apps with the same connection. Example: once you enter credentials for Gmail they are automatically ready to use for Google Drive.

The native app Email includes a module Send an Email to a Team Member that users can put in their scenarios that automatically sends the specified person an email with a custom subject and body. To offer this module, you need to add the following parameters in JSON in the Email app's common data. The from object lets you define the user and email address your users receive these emails from.

1. Go to Administration > Native Apps.

2. Click Email.

3. Click the App: 7.3.19 tab.

4. Click the toggle for Send an Email to a Team Member to make it visible and accessible for your users.

5. In the Common data field, create an enter a JSON object using the parameters and example below.

6. Click the save icon to save your changes.

1. Log in to Okta and go to Admin > Applications > Applications.

2. Click Create app integration and select SAML 2.0.

3. Name your app and upload your icon.

4. Click Next.

5. Configure the following SAML settings including:

1. Click Show advanced settings and enter the following:

1. Enter the following attributes and click Next.

1. In the Are you a customer or partner? field, select I'm an Okta customer adding an internal app.

2. In the App type field, select This is an internal app that we have created

3. Click Finish.

To locate your IdP login URL and certificate:

1. Go to Admin > Applications > Applications and select your SAML SSO app. to access the necessary information.

2. Go to the Sign on tab and click View SAML setup instructions.

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 following chart contains the app alias, connection alias, required permissions, and Microsoft API for each Microsoft app in Make.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Databases

Message Queues

Filesystem

Public-facing changes

Make AI Toolkit

Make AI Toolkit is an app that streamlines common AI tasks using either Make's built-in AI Provider or your own external AI models. The toolkit offers essential capabilities including sentiment analysis, text categorization, language identification, information extraction, text standardization, summarization, translation, and text chunking.

Make AI Content Extractor

We've released a built-in app that extracts structured text and metadata from files like PDFs, Word documents, images, and audio recordings—directly within your Make scenarios.

Fix for Team Restricted Member role permission

We've fixed an issue with the permissions assigned to the Team Restricted Member role. The role now does not have any unexpected modification capabilities.

What we fixed

We've removed the permission that allowed the Team Restricted Member role to modify team settings.

What this means for you

If you have the Team Restricted Member role, you will no longer be able to modify any team settings for the team you are a part of.

The Team Restricted Member role remains supported for existing teams, even though it is considered deprecated. This fix allows the role to function securely and in the way it was originally intended.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Databases

Message Queues

Filesystem

Current service version numbers

The following are the current version numbers for services. You can verify them in your instance by going to Administration > Monitoring.

Public-facing changes

Improvements and changes

• As an increased security measure, we’ve updated our process for deleting an account. Now, if you’d like to delete your account, you’ll be asked to provide the same level of verification that is required for administering your account. For example, if you have 2FA enabled, that will be required for deleting an account.

• It’s now possible to add or change your payment method on the Subscriptions page. You can still add your payment method from the Organization settings dropdown as well.

• We’ve added a new section in the organization dashboard: now you can monitor all your scenarios that Make automatically disabled due to some error appeared in a scenario.

Fixed issues

• Users rarely couldn’t see the operation usage in their organization dashboards. This is fixed now.

• Under specific conditions, the polling trigger starting point could reset to the original setting when you created the trigger. We fixed the issue, so the polling trigger metadata are always correct.

• When the HTTP module returned invalid Unicode characters after you ran the scenario manually, you couldn’t save the scenario. This is no longer happening.

Apps updates

New apps:

• - With a new Skai app, you can configure a report and run it, as well as download a report file.

Updated apps:

• - Deals are now called Pipelines in Bigin by Zoho CRM. Our modules have been updated to match this change.

• - The app is called LinkedIn Conversions API and now includes a new module, Send Conversion Events. Additionally, we added a new connection type that allows connecting via OpenID Connect for enhanced security.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Databases

Message Queues

Filesystem

Current service version numbers

The following are the current version numbers for services. You can verify them in your instance by going to Administration > Monitoring.

Public-facing changes

Improvements and changes

• We revamped the toolbar in our scenario editor! We have made numerous visual and functionality improvements, like moving the Run once button into the toolbar or making the toolbar expandable. Read more about the new toolbar .

• The are have left the closed beta and are now available to users in organizations with the Teams or Enterprise plan.

• The custom IML function for developing custom apps has been re-enabled! It was disabled because of security reasons, and is now available again.

• We are migrating the existing custom apps to the new technology in batches, so it might take time until you can edit a custom IML function in an already existing custom app. You can read more about the re-enablement here.

Fixed issues

• We fixed a bug that was causing an error when multiple scenarios were called in an array using the scenario ID. Now, multiple scenario ID values are passed in the scenario URL.

Documentation updates

• - We've updated the article to include complete information on each module type, along with their features and ways of usage. The advanced tips section offers expert users new tricks and examples for working with modules.

• Make Public API Documentation - We published the documentation for the keys API. You can check it out on our .

Apps updates

New apps:

• - Easily edit images with the new Schogini Image Wizard app, allowing you to blur, resize, rotate, and more, all within Make.

• - Watch new leads in your Poper account using the new app in Make.

Updated apps:

• - We’ve created a custom function that lets you apply padding to any values across all SAP ECC Agent modules.

• - Starting November 1, MailerSend has made changes that affect all modules. Check out the article and take the necessary steps to ensure smooth work with MailerSend.

• - There is a new Make an API Call module for Anthropic Claude.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Databases

Message Queues

Filesystem

Current service version numbers

The following are the current version numbers for services. You can verify them in your instance by going to Administration > Monitoring.

Public facing changes

• Previously, when users reduced the number of settings in the module settings window, it didn't automatically adjust its size. But now, the window shrinks based on the number of settings you have.

• When users searched for an app to add to the Favorites list, the search didn't show results. We fixed it: users can search for an app and get relevant results.

• After users tried to resolve the Incomplete execution, the diagram didn't load. This UX issue doesn't exist anymore.

• fter users deleted a custom variable, an incorrect warning message popped up when you tried to save the scenario.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization

Current software version numbers

The following is a list of current software versions running in Make's release environment. You can also find announcements of planned updates and upcoming end-of-life support for specific versions here.

Containerization