Governance in Make: A Practical Model for Privacy, Access, and Auditability

Governance in Make is not one setting that gives administrators complete visibility. It is a combination of controls with different jobs: Private Spaces isolate builder work and limit credit use, Custom Roles and teams shape access, Audit Logs support retrospective investigation, and credential-use emails provide a limited change signal.

That distinction matters in practice. A RevOps builder might prototype a CRM scenario in a Private Space while an administrator reviews access boundaries and a credential owner checks an email when their connection is added to a scenario. None of those controls, alone or together, should be treated as a live execution-monitoring system.

This guide focuses on documented Make capabilities and an organization-designed review process. It does not assume an undocumented Make-to-SIEM integration, export path, per-execution credential alert, or vendor-provided governance template.

What governance in Make should accomplish

Start with the operational question. Are you trying to protect unfinished builder work, limit what a person can do, investigate a recorded event, or notice when a credential is introduced into a scenario? Each requirement points to a different control.

In this model, isolation gives builders room to work, access controls limit actions, logs and notifications provide specific evidence or signals, and an internal review process decides what happens next. Governance is therefore a combination of prevention, isolation, detection, and review rather than unrestricted administrator visibility.

Choose the right control for the job

The table below routes common requirements to the relevant Make control. Availability and behavior reflect official documentation reviewed on October 15, 2026.

Control	Best fit	Important boundary
Private Spaces	Isolate member work and set credit limits. Available on all plans, including Free, but an Admin must enable the feature.	Guests are excluded. On Enterprise, Admin visibility is limited to metadata, not scenario settings, connections, or run details.
Custom Roles and teams	Grant defined organization-level or team-level permissions. Custom Roles are Enterprise-only.	Team permissions apply across resources of the relevant type in that team, not selected individual scenarios. Use separate teams for a narrower boundary.
Audit Logs	Investigate documented events after they occur. Enterprise-only.	Retention is 12 months. Event availability varies by organization or team scope, and logs are not a general run-history warehouse.
Connection and key usage emails	Notify an owner when a team member first adds the owner’s credential to a scenario. Available on all plans.	They are not documented as emails for every scenario execution. Settings are configurable for each owned connection or key.
Credential Requests	Collect app credentials through Make without exposing authentication details to the requester.	Available to eligible Enterprise customers and official Make Partners, subject to enablement and eligibility review.
2FA enforcement	Require 2FA for users of Make’s native email-and-password login. Enterprise capability.	Google and SSO/SAML users need enforcement through their identity provider. Enabling enforcement can immediately sign out affected native-login users.
Feature controls	Toggle listed AI and beta capabilities across the organization. Enterprise capability.	They are not a permission system for ordinary application modules. Disabling a capability may affect active scenarios.

Use separate teams when someone must not see every scenario or connection of a resource type in an existing team. A Custom Role narrows actions within a team, but it does not create an individual-resource allowlist.

Set up builder privacy without mistaking it for observability

Private Spaces provide isolated workspaces for organization members other than guests once an Admin enables the feature. Members can build privately and share completed work separately. An Admin can set a monthly or yearly organization-wide credit limit and individual member limits. When a limit is reached, scenario runs pause, but the member can continue building. A zero limit pauses that space.

On Enterprise, an organization owner can enable limited, read-only Admin visibility. Administrators can see scenario names, modules used, and credit usage. They cannot see module settings, run history, run details, data stores, or connections. In a RevOps example, that view can show that a prototype uses CRM-related modules and consumes credits, but it cannot replace a pre-production review of credentials, payloads, or runtime behavior.

See Make’s Private Spaces documentation for current configuration and visibility details.

Disabling Private Spaces is a destructive change. Make documents that disabling the feature permanently deletes private-space contents, including scenarios, connections, and data stores, and stops running scenarios. Before disabling it, identify affected assets and active scenarios, preserve work that must be retained, obtain owner approval, and record the change.

Design access around roles and team boundaries

Enterprise organization Admins and Owners can create Custom Roles from Make’s predefined permission list at organization or team level. Organization-level permissions govern access across the organization, while team-level permissions govern access to a specific team. Review permission dependencies and the implications of broad permissions before assigning a role.

The important limitation is resource granularity. Team-role permissions apply to all resources of the relevant type in that team, not a hand-picked subset of scenarios or connections. If an operator must run every scenario in one team but only one scenario in another, put those resources behind separate team boundaries rather than expecting the role to create a per-scenario allowlist.

Make’s Custom Roles guide explains role scope and permission setup.

A permission matrix can help an organization review access before configuring Make. This is an internal planning aid, not a Make data model:

role_name: scenario_operator
role_scope: team
can_view_scenarios: yes
can_run_scenarios: yes
can_edit_scenarios: no
can_manage_connections: no
team_boundary: revops_production
approval_owner: revops_owner
review_date: 2026-11-15

For each role, map responsibilities to the minimum required permissions, choose the narrowest suitable scope, check dependencies, assign the role, and validate access against the full set of resources in that team. If the boundary is too broad, reorganize the teams before granting access.

Make’s governance announcement says Custom Role lifecycle activity is recorded in Audit Logs. The current Audit Logs event documentation explicitly lists Custom role deleted but does not enumerate every creation, update, and assignment event in the same way. Confirm the specific event coverage in the organization’s tenant before relying on a particular lifecycle event for an investigation. See the Make governance announcement and Audit Logs documentation.

Use Audit Logs for investigation, not runtime analytics

Audit Logs are Enterprise-only, retained for 12 months, and available according to the reviewer’s organization or team permissions. Make documents events across areas such as identity and access, credentials and keys, Private Spaces, and organization or team resources. Exact events visible depend on log scope. A team log does not include every organization-level event.

For a retrospective question, use this sequence:

1. Define the question and time window. For example, determine whether a role changed during a specified access-review period.
2. Select the scope. Choose organization or team logs based on where the event would be recorded and who has permission to inspect it.
3. Filter and inspect. Filter by event, user, time, and team where available. Open event details and record the finding in the organization’s incident or review process.
4. Preserve the grain. Keep the recorded event separate from a scenario configuration change, notification email, and runtime execution. One does not establish the others.

The reviewed documentation does not establish a complete external export or API specification, immutable event identifier, or deduplication contract. If an external register or SIEM feed is required, confirm the supported access path, event grain, and stable identifier with Make before designing ingestion. Do not use a lookup-then-create check as the only concurrency safeguard. If a confirmed stable identifier is available, preserve one record per source event and use a database-enforced uniqueness rule or transactional upsert.

Interpret credential-use notifications correctly

Make documents an email to the credential owner the first time a team member adds the owner’s connection or key to a scenario by creating, updating, or cloning that scenario. Notifications are available on all plans, enabled by default, and configurable separately for each owned connection or key.

The documented trigger is not an email for every later scenario execution. Enterprise Audit Logs also document related non-owner credential-use events, but an email and an Audit Log event are not interchangeable telemetry.

If runtime execution monitoring is required, verify a separate supported mechanism instead of deriving it from this notification. The connection and key notification guide describes the trigger and per-credential settings.

Add related controls without overstating their scope

Credential Requests

Eligible Enterprise customers and official Make Partners can use Credential Requests after the feature is enabled and eligibility is confirmed. A requester specifies the app credentials needed and shares a request link. The recipient enters authentication details directly in Make, where they are not exposed to the requester. Recipients can revoke, reauthorize, or edit access. Use this only when the eligibility conditions are met and requested app permissions are appropriately scoped. See Make’s Credential Requests documentation.

Two-factor authentication enforcement

Enterprise Make-level enforcement applies to users who sign in with Make’s native email-and-password authentication. Users signing in through Google or SSO/SAML need 2FA enforcement through the external identity provider. Enabling enforcement can immediately sign out native-login users who have not configured 2FA. Identify affected users and communicate the change before rollout. Make documents this behavior in its 2FA enforcement guide.

Feature controls

Enterprise administrators can toggle listed AI and beta capabilities organization-wide. These controls are not ordinary application-module permissions, and disabling a capability may affect active scenarios that use it. Inventory affected scenarios and assign an owner to assess the impact before changing a setting. Feature controls do not replace data classification, credential scoping, scenario review, or destination-system validation. See the Feature controls documentation.

A practical governance review sequence

Make the control owner and evidence source explicit for each decision. A production promotion or approval gate can be useful, but it is an organization-designed procedure, not a built-in Make workflow.

1. Define the requirement and owner. State whether the need is privacy, access restriction, retrospective evidence, credential awareness, or feature control. Name the person accountable for exceptions.
2. Isolate builder work. Enable Private Spaces where appropriate, set credit limits, decide whether Enterprise metadata visibility is suitable, and document how completed scenarios will be shared.
3. Set role and team boundaries. Map responsibilities to permissions, create roles at the narrowest suitable scope, and use separate teams when access must be limited to selected resources.
4. Configure credential and identity controls. Review per-credential email settings, assess Credential Requests eligibility, and plan native-login 2FA enforcement or identity-provider enforcement as appropriate.
5. Establish review and change controls. Assign a reviewer for Audit Logs where available, define the review question and schedule, and require documented approval before destructive Private Space changes or disruptive feature toggles.

Measure the operating process with checks the organization can verify: the share of production scenarios with a named owner, completion of scheduled access reviews, unresolved credential-use alerts, and approval records for destructive Private Space changes. These are internal measures, not Make-provided governance metrics.

For help designing or reviewing the organization’s Make operating procedures, visit Make automation consulting.

Make’s documentation and plan availability can change. The verified product statements in this guide reflect official documentation reviewed on October 15, 2026. Make’s governance announcement currently displays August 4, 2026 as its visible publication date.