Access control

Every environment has its own gate for END USERS — separate from who can log into this dashboard. Access control decides whether someone can open the add-in at all, and which of its functions they're allowed to call.

This is not the same audience as Members & roles. That page covers people who sign into this dashboard to configure ConnXL. This page covers the people who open your add-in in Excel and type =NAMESPACE.MODULE.FN(…) — your end users, who may never touch the dashboard at all.

Access control is configured per environment (a Development add-in and its Production counterpart can have entirely different rules), under the environment's Access area in the dashboard, split into six tabs: Sign-in, Visibility, Audience, Permissions, Network, and Activity.

Nothing in this page has any effect until at least one identity provider is connected and enabled. Add one or more from the Sign-in tab:

entra — Microsoft Entra ID (Azure AD). One connection per environment.
google — Google Workspace. One connection per environment.
microsoft-personal — a PERSONAL Microsoft account (outlook.com / hotmail.com / live.com). Entra covers work and school directories only. One connection per environment.
oidc — a generic OpenID Connect provider (Okta, Auth0, or any standards-compliant IdP). Unbounded — connect as many as you need, side by side.

Each provider is independently enabled or disabled. The fields shown depend on the type — see Identity provider setup for where to find each value:

Field	Type	Description
`displayName`Optional	`string`	The label shown on the sign-in button (defaults to the provider type name).
`tenantId`Entra	`string`	Your Entra tenant ID. Not required — and not shown — when the provider is set to accept any Microsoft organization (see below).
`clientId`Required	`string`	The application (client) ID registered with the provider.
`resourceUri`Entra	`string`	The Application ID URI the agent presents as the token audience.
`issuerUrl`OIDC	`URL`	The OIDC issuer base URL (e.g. `https://your-tenant.okta.com`).
`scopes`Optional	`string[]`	Additional OAuth scopes to request beyond the provider default.
`clientSecret`Required	`secret://…`	A reference to the OAuth client secret. Write-only — once saved, the dashboard only ever shows that a secret is set, never its value.

There is no separate "require sign-in" switch — sign-in is enforced automatically the moment any provider above is enabled.

Entra: one organization, or any organization

An Entra provider asks one more question: who can sign in.

Only my organization (the default) — only people in the tenant you named in tenantId. Anyone from another Microsoft directory is refused before any rule on this page is even consulted.
Any Microsoft organization — people from other companies can sign in too, subject to your Audience and Permissions below. tenantId disappears, because there is no single directory left to pin.

The second option is for an add-in you share with partners, clients, or contractors who live in their own Microsoft tenants. It does not mean "open to everyone": every caller still has to clear the Audience and Permissions rules below, so a Private environment still only admits the people you invited or the domains you allowed.

Any-organization needs two changes in your own Azure app registration

Neither of these is something ConnXL can set for you, and both cause sign-in to fail if they're missed:

Your app registration must be multi-tenant — "Accounts in any organizational directory" in Azure. If it's single-tenant, Microsoft itself refuses outside sign-ins at its own login page, before the request ever reaches your agent.
It must request the xms_edov optional claim on the Access token — Azure → your app registration → Token configuration → Add optional claim → Access → xms_edov. (The portal may warn that the claim isn't recognized; that warning is safe to ignore.) This claim is how Microsoft tells us an email address really belongs to the person signing in. Without a tenant to pin, it's the only thing standing between your allowlist and someone who spun up their own directory and typed one of your users' addresses into it — so we refuse every sign-in that arrives without it, rather than trusting the address.

No provider enabled means no gate at all

Until at least one provider is enabled, sign-in cannot be enforced — anyone who can reach the agent's host can call every function, regardless of what Visibility or Audience say below. A banner on every Access tab reminds you of this until it's resolved.

Choose Public or Private

The Visibility tab is the headline switch, and it's the same defaultAccess setting the Permissions tab falls back to for anyone with no explicit grant:

Private (the default) — only the audience you define below gets in.
Public — anyone who can sign in with a connected provider may open the add-in and call its functions, subject to whatever Permissions deny.

Flipping to Public exposes every function in every namespace to anyone in your organization's identity provider, so the dashboard asks you to confirm the change before it takes effect.

Define the audience

The Audience tab is where a Private environment's allowed callers are defined (Groups still matter in Public environments too, since Permissions grants target them). Three mechanisms, plus a blocklist that applies either way:

Field	Type	Description
`Members`Optional	—	Invite individual end users by email. A member is `invited` until they first sign in, then `active`; you can `revoke` access (re-invite later) or remove a member permanently.
`Allowed domains`Optional	—	Everyone with an email at a given domain gets in — e.g. add `acme.com` to let the whole company through without inviting each person.
`Groups`Optional	—	A named bundle of principals — individual emails, whole domains, or an identity-provider group claim from the signed-in token — so a single Permissions grant can cover an entire team at once.
`Denied domains`Optional	—	A blocklist that applies in BOTH Public and Private environments — a deny always overrides a matching allow, everywhere in this system.

Grant access to functions and resources

The Permissions tab is where you go from "who's allowed in" to "what they're allowed to call":

The group × namespace grid — every managed group as a row, every Excel namespace (the MODULE in MODULE.FN) your functions live in as a column. Click a cell to cycle it through Inherit → Allow → Deny → Inherit. Inherit means the group has no explicit grant on that namespace, so it falls back to the Visibility setting above.
Individual grants — allow or deny a specific email or domain against * (every function), a whole namespace (MODULE.*), or one exact function — for cases a group doesn't cover.
Per-function grants — open any function's own detail page for a dedicated card that grants or denies specific groups, emails, or domains for just that one function, overriding the broader namespace rule.

A deny always wins over a matching allow, at every level — a group allowed on a whole namespace can still be denied one specific function inside it.

Restrict by network

The Network tab adds IP-based rules on top of everything above: an IPv4 CIDR range (or a bare address, treated as /32), an allow or deny effect, and a scope (*, a namespace, or one function). The agent checks the caller's request IP against these rules at execution time — inside your own network, closest to the data. IPv6 ranges aren't supported yet.

Review the activity log

The Activity tab is an append-only audit trail for the environment: every sign-in, denied call, permission change, and revocation, filterable by event kind.

The actor is never a raw email

Activity entries identify the caller by a hash, not their email address — the log is privacy-safe to browse and share by default, while still letting you correlate events back to the same person over time.

Members & roles

Who can log into the dashboard itself and change your configuration.

Billing

The per-add-in subscription, invoices, and cancellation.