GLYDE Unity + Microsoft Power Platform

Overview

Many organizations keep GLYDE Unity automations in a dedicated Power Platform environment: a separate container with its own flows, connections, custom connectors, and access list. This keeps GLYDE automations isolated from day-to-day business flows, lets you scope access to a small named group, and gives GLYDE staff a controlled place to build alongside your team.

Everything in this guide uses standard Microsoft capabilities: Microsoft Entra B2B guest accounts, environment security groups, per-environment custom connectors, and cloud flow owner sharing. Your tenant stays in control of identity, licensing, data policies, and audit at all times. The only GLYDE component in your tenant is the GLYDE custom connector definition you install in the dedicated environment.

What works, at a glance

Prerequisites

• A Power Platform administrator or Global administrator - creating environments, managing security groups, and inviting guest users each need at least this role.
• Microsoft Entra external collaboration must be allowed for your tenant (the default). If either organization restricts cross-tenant access, your Entra admin can allow B2B collaboration for the other tenant in cross-tenant access settings.
• Each maker needs a Power Automate license assigned to their account - see the licensing section below. Building flows that call a custom connector requires Power Automate Premium, and security-group membership never grants a license by itself.
• Your GLYDE environment is live with API access, and each maker (yours and GLYDE guest staff) has a GLYDE account and API key for their connection.
• To create an environment with a Dataverse database, your tenant needs at least 1 GB of available database capacity.

Step 1 - Create the makers group and invite GLYDE staff as guests

1. In the Microsoft Entra admin center, go to Identity → Groups → All groups → New group. Choose type Security and a clear name such as GLYDE Unity Flow Makers.
2. Add your internal staff who will build or manage GLYDE flows as members of the group.
3. Invite GLYDE staff as guests: Identity → External identities → Users → New guest user, using the GLYDE work email addresses provided by your GLYDE contact. Alternatively, add the guest accounts directly as members of the group and Microsoft Entra sends the invitations for you.
4. Ask each GLYDE guest to accept the invitation (email link) and sign in once. Guests who have not accepted the invitation cannot be added to environments, flows, or approvals.

Step 2 - Create the dedicated environment

1. In the Power Platform admin center, go to Manage → Environments → + New.
2. Name it (for example GLYDE Unity) and choose the type: Production for business-critical automations, or Sandbox for a pilot (sandboxes support copy and reset, but treat them as non-production).
3. Pick the region you want flows and connections to run in. The region is fixed at creation.
4. Create a Dataverse database for the environment (recommended): it enables solutions - including GLYDE solution and template packs - and solution-aware flows with cleaner lifecycle management. If you only plan basic flow building you can skip it, but skip Steps 3 and 4 below in that case.
5. Under security, associate the environment with the GLYDE Unity Flow Makers security group from Step 1, so only group members are added to the environment.
6. After creation, open the environment and note its Environment ID (a GUID, shown on the environment details page). You will need it in Step 5.

Step 3 - Allow guest access in the environment

New environments block guest access to Dataverse by default, so GLYDE guests cannot work in the environment until an admin allows it. This setting is per environment - enabling it here does not open any other environment.

1. In the Power Platform admin center, open Security Hub → Identity and access and locate the Guest access setting.
2. Select the new environment, set the toggle to Off (Allowed), and Save.
3. Alternatively, allow it from the Power Platform CLI: pac env update-settings --environment "<environment-url>" --name "restrictGuestUserAccess" --value false

Not applicable if you skipped the Dataverse database: the guest access restriction only governs Dataverse resources.

Step 4 - Grant the Environment Maker role

In environments with a Dataverse database, group members are added to the environment through the security group, but they are not automatically granted maker rights in non-default environments.

1. In the Power Platform admin center, open the environment and go to Settings → Users + permissions → Users. Confirm the group members (including GLYDE guests) appear. Guests are frequently not auto-provisioned - if a guest is missing, use Add user to add them by email before assigning any role.
2. Select the makers (or add them as a team from the security group), choose Manage security roles, and assign Environment Maker. Allow up to 10 minutes after role changes before testing.
3. Confirm each maker can open the environment and see the Flows experience. GLYDE guests enter through Power Apps, not Power Automate: open https://make.powerapps.com/?tenant=<your tenant ID>, accept the one-time consent prompt, select the environment in the picker, and use Flows in the left navigation - the full flow-building experience runs there, including Shared with me for flows shared with the guest.

The Environment Maker role is exactly what the name says: create and edit flows, connections, and custom connectors in this environment. It grants no access to other environments.

Step 5 - Install the GLYDE connector into this environment

Custom connectors live inside a specific environment, so the GLYDE connector must be installed in the new environment (flows there cannot use a connector installed only in your default environment).

1. Ask a maker who belongs to the environment (or your Power Platform admin) to open the GLYDE Teams app and go to quick-links → Power Automate, or the setup wizard’s optional integrations step, and open the connector installer.
2. Paste the Environment ID GUID from Step 2 into the environment field - leave it blank and the installer would fall back to your tenant default environment, which is not where you want it.
3. Run the install, and use the consent buttons if Microsoft asks for additional permissions, then retry.
4. Alternatively, ask GLYDE support to run the tenant install for you; provide them the same Environment ID.

Step 6 - Connections and sharing flows with GLYDE guests

Connections

Every maker - your staff and GLYDE guests - creates their own GLYDE connection the first time they add a GLYDE action: sign in with the GLYDE API key issued to them plus their work email. A flow acts with the permissions of the user whose connection it uses, so different makers can safely co-own the same flow while their GLYDE actions run under their own visibility.

Sharing

1. In Power Automate → My flows, select the flow’s … → Share.
2. Type the GLYDE guest’s name or email and add them as an owner. Owners can view run history, edit the flow, turn it on and off, and manage other owners.
3. For people who only need to run an instant flow (not edit it), add them under Run only users instead.

Keep at least one owner from your own organization on every flow. Note that a co-owner cannot reset the credentials of a connection created by another owner; if a connection owner leaves, edit the affected steps to use a new connection.

Sharing in the other direction (guest-owned flows)

When a GLYDE guest creates a flow and tries to add one of your users as a co-owner, the share picker may find nobody: the picker queries your directory as the guest, and by default Microsoft Entra gives guests only limited directory visibility. Two ways through:

• Quick test: type the user’s full email address verbatim in the share box - typed addresses sometimes resolve even when search returns nothing.
• Durable fix (your Entra admin): External identities → External collaboration settings → Guest user access set to “Guest users have the same access as members”. This is also Microsoft’s documented prerequisite for guest makers. The trade-off is that guests can then enumerate your directory - acceptable here because guests are scoped to the makers security group.
• Structural alternative: build flows solution-aware and move them to a production environment by solution export/import - the importing user becomes the owner, sidestepping guest-to-host sharing entirely (see Running in production).

Guest sign-in - the one URL that matters

GLYDE guests do not reach this environment through make.powerautomate.com: that portal binds a guest’s session to their home tenant, ignores deep links and tenant hints, and shows an empty environment picker (every environment request is refused with the home-tenant token - which is why “no Power Automate app and no environment” looks like a permissions problem but is not one).

1. GLYDE guests sign in at https://make.powerapps.com/?tenant=<your tenant ID> and accept the one-time consent prompt on first use. Share this URL with them - it is worth bookmarking per customer.
2. Select the dedicated environment in the picker, then use Flows in the left navigation: the full flow-building experience runs there, including Shared with me for flows shared with the guest.
3. To confirm which tenant a session is really in, call listUserDetails from the browser console - isGuestUser must be true - or decode any Bearer token and check its tid.

Licensing at a glance

Governance and data policies

• Data loss prevention (DLP): check that a DLP policy covering this environment classifies the GLYDE custom connector as Business (or Non-Business) rather than Blocked. Flows using a blocked connector cannot be saved or run.
• Access reviews: periodically review the makers security group and the owner list of each flow. Guest access to the environment can be switched off at any time from the Power Platform admin center.
• Environment isolation: DLP policies, connections, and custom connectors are all environment-scoped, which is what keeps GLYDE flows cleanly separated from the rest of your automation estate.

Running the flows in production - choosing the environment type

Nothing technically stops flows from running in a Sandbox environment, but a sandbox is a disposable container: it can be reset or deleted without admin confirmation, its backups are fixed at 7 days, and it is licensed and intended for development and test. Running your business automation from one means running it somewhere it can be wiped on a click. One further trap specific to this pattern: automated and scheduled flows run under the flow owner’s license - a production flow owned solely by a GLYDE guest account couples your operations to an external account staying licensed and enabled.

Option A - one environment, convert it

When this environment is the production home, convert it: Power Platform admin center → environment → Settings → Properties → Environment type → Production. Nothing breaks - flows, connections, and custom connectors all stay; the environment gains production protection and backup semantics. The conversion cannot be reversed back to sandbox. Pair it with the sharing guidance above so every flow carries at least one owner from your organization.

Option B - build in sandbox, run in production (recommended)

1. Keep this environment as the build environment where GLYDE staff and your makers co-create as described in this guide.
2. Create a separate Production environment owned by your organization (same security-group pattern if you wish).
3. Build flows solution-aware (inside a solution in the build environment) and move them with solution export/import. On import, the importing user from your organization becomes the flow owner - production ownership lands with you structurally, and connection references are re-authenticated on import so production connections are yours.
4. GLYDE guests remain useful in production as co-owners for support, while the licensed owner of record is one of your accounts - or assign a flow a Process license so no per-user license is required at all.

Option A is the minimal change; Option B is the better long-term shape - customer-owned production, GLYDE-owned delivery - and it makes the guest-sharing limitation largely moot.

Known limitations

• Guests must accept the B2B invitation before they can be added to the environment, flows, or approval lists.
• The Power Automate tile does not appear in the Microsoft 365 “My apps” launcher for guests - that is expected, not a setup failure. Guests enter via the Power Apps URL in the Guest sign-in section.
• Guests act on approvals in the Power Automate portal; actionable approval emails in Outlook are not supported for guest users, and approvals do not follow guests across tenant contexts.
• A co-owner cannot modify the credentials of a connection owned by another user; they can use it, but the owner must fix expired credentials.
• Guest-owned flows may be unable to add your users as co-owners: the share picker queries your directory as the guest, and default guest directory visibility hides your users. Fix via External collaboration settings (same access as members), typed full email addresses, or the solution-based pattern in Running in production.
• Guests cannot reach the environment through make.powerautomate.com: that portal binds a guest’s session to their home tenant, ignores deep links and tenant hints, and shows an empty picker (every environment request 403s with the home-tenant token). The verified entry is https://make.powerapps.com/?tenant=<your tenant ID> - Power Apps honors the tenant hint, its picker lists guest environments, and its Flows section is the full maker experience. To confirm which tenant a session is really in, call listUserDetails from the browser console (isGuestUser must be true) or decode any Bearer token and check its tid.
• Creating an environment with a Dataverse database consumes tenant database capacity (1 GB minimum must be available).
• If you also use the GLYDE MCP connector for Copilot Studio, it is imported separately (Copilot Studio → custom connector import) in the environment where your agent lives.
• Do not use the tenant default environment for this pattern: every internal user is a maker there by default, guests cannot be scoped the same way, and Microsoft recommends it for personal productivity rather than business-critical flows.

Verification checklist

Run through this list with a GLYDE guest maker before go-live:

1. Each guest has a Power Automate Premium license assigned in either tenant, and has the Guest sign-in URL from the section below.
2. The guest opens https://make.powerapps.com/?tenant=<your tenant ID> with their GLYDE work account and can open the dedicated environment.
3. The GLYDE connector appears under connectors in that environment, and the guest can create a working connection with their GLYDE API key and work email.
4. A maker from your organization creates a test flow with a GLYDE action, shares it with the guest as an owner, and the guest appears in the share picker.
5. The guest edits the shared flow and runs a successful test end to end.
6. Your admin confirms the environment’s DLP policy permits the GLYDE connector and the makers group contains only the intended people.

Where to get help

Your GLYDE contact can review the environment configuration with you, confirm licensing questions, and (if you prefer) install the connector into the environment for you when you provide the Environment ID. For flow-building help, see the Power Automate page in the GLYDE Teams app or chat with GLYDE Support.

Version history