Support access

How e6data Support Users work - scoped, aliased, fully audited e6data engineer access that you can revoke at any time.

This section explains how e6data Support Users work in your organization: how they are added, what they can see, how they are audited, and how you stay in control of their access.

This guide is for organization admins and security and compliance reviewers.

What is a Support User?

A Support User is an e6data engineer who has been granted scoped access to your organization to help debug an issue, validate a configuration, or assist with onboarding.

Three properties distinguish a Support User from a regular member of your organization:

1. Identity is e6data, not a third party. Only accounts on @e6x.io or @e6data.com can ever be added as Support Users. Customer-owned emails are rejected.
2. They are transparently labelled. Every customer-facing surface - user list, audit log, query attribution, workspace members - marks the account as a Support User and renders it under a per-organization alias such as support-1, support-2, …, with the email shown as [email protected]. The engineer's real email is never exposed to your organization.
3. You can revoke at any time. A per-tenant block is honoured immediately and propagated to every workspace. A blocked Support User cannot log in to your organization and cannot self-rejoin.

Lifecycle at a glance

A Support User moves through a small set of states:

• Bound - added to your organization, assigned an alias, and granted the configured support role. Once bound, the Support User is synced to every workspace automatically (typically within about 30 seconds).
• Blocked - denied entry to your organization. Roles are preserved so you can restore access by unblocking later, but login and tenant access are refused immediately.
• Removed - the alias is released back to the pool for reuse, while an alias-history record is retained so past audit entries still resolve correctly.

A Support User becomes bound in one of two ways: an admin invites them (the default for planned engagements), or - for incident response - an e6data engineer self-binds. A self-bind is always rejected if your organization has blocked that engineer. See Enable, audit, and block support access.

In this section

• Enable, audit, and block support access - add, block, unblock, and audit Support Users.
• Privacy controls - the per-tenant alias model, what is and isn't recorded, and the security guarantees.

FAQ

Can the e6data engineer see my data without me knowing? No. Every action is attributed to support-N in your audit log, including query execution, and the Support User is surfaced in your user list and workspace member list with isSupportUser: true.

Can a Support User add themselves to my organization without us doing anything? Yes, by design - for incident response, e6data engineers can self-bind. But only @e6x.io / @e6data.com accounts can; every self-bind is audited; any past or future block of that engineer rejects the self-bind; and you can block them immediately afterwards if the engagement was not authorized.

What if we want a read-only Support User? Pass "roles": ["viewer"] (or any custom read-only role you've defined) when adding the Support User. Note that a self-bind currently always uses the default support role; if you require read-only by default for self-binds, contact your account team.

The same alias number was used by a different engineer a year ago. Will that confuse our audit log? No. The audit log resolves support-N to the engineer who held that alias at the timestamp of the action, through the alias-history record. Reuse is safe - see Privacy controls.

How do I get the real identity behind a support-N alias if compliance requires it? Contact your e6data account team. The mapping is preserved internally and is available under your standard support contract.