xAutodocs Sign in

Projects, members, teams, branding, limits, and what a lapsed subscription does (and does not) take away.

Organization, branding, plans and billing

Organization holds four tabs: Projects, Access, Plan & billing and Brand. All four are administration of the tenant rather than of what is running in it, which is why they share one nav entry and one permission gate — an operator holding none of the organization-administration permissions does not see this entry at all.

Access holds three views behind a segmented control: People, Teams and Roles. They are one model in three layers rather than three subjects — a role defines a permission set, a team bundles grants, a membership assigns them — so answering "why can this person deploy to Production" means reading all three together. Roles appears only for an operator who can edit them.

Projects

Projects are created, renamed, transferred and deleted here, along with their environments and connections. Manage also holds the project's alert settings, network restrictions and approval policy. It is the one tab reached daily rather than quarterly, so it is where this screen opens by default and where somebody with no project selected is sent — creating one is the single action that unlocks the project-scoped screens in the app.

Access → People

Inviting somebody sends them an email and creates a pending invitation, which is redeemed automatically the first time they sign in with that address. The email carries no accept link and no token — sign-on is federated, so access comes from proving control of the address at GitHub, Microsoft or Google, and there is nothing a link could grant. Forwarding the invitation grants nothing.

The invited address must be the one they actually sign in with. Somebody who picks a different provider identity does not get an error — they get a brand-new organization of their own, which looks exactly like the invitation having failed.

A pending invitation reserves a seat. That is why members and invitations are listed together with the breakdown visible: apart, the seat count looks wrong to whoever counts the people they can see. Declining or letting an invitation expire releases the seat.

Access editing — a project override, an environment assignment — is one control per member. A team grants the same kinds of access to several people at once, from the Teams view beside it, and a person's effective access is everything their membership and every team they are on grant together. See Roles and access.

Remove takes somebody out of this organization. Revoke account ends their access everywhere, on the platform. They are deliberately worded differently because they are very different acts.

Verified email domains

Access → People → Access settings can define a standing auto-join rule for a company email domain. A rule chooses the member's default role and can place new joiners into teams, but grants nothing until ownership of the domain is verified. Public email providers cannot be claimed.

People who already joined keep their membership if the rule is later removed; the removal only stops future automatic joins and releases the domain for another organization to claim.

Plan and limits

Plans cap projects, connections, tracked resources and members, and gate a set of capabilities. Two things about how a refusal reads:

  • A limit refusal names the plan that would fit. It is checked atomically against the write that would exceed it, so two admins creating against one remaining slot cannot both succeed.

  • A capability you do not have is hidden, not shown-and-refused. A screen that appears and then refuses everything cannot be told from a broken one.

A negotiated plan is possible and is arranged with your account manager rather than through the self-serve checkout. If you are on one, refusals point you at them rather than naming a catalog plan your contract does not correspond to.

Brand

The Brand tab changes how this organization appears: product name, website and legal links, accent colour and the sign-in mark. Configuring it requires the plan's white-label capability and the manage-branding permission. Where custom hosting is configured, the organization can also claim a subdomain and configure a branded email sender. Domain and sender verification are explicit states; entering a name does not imply DNS is ready.

Existing branding remains visible after a downgrade even though it cannot be edited. Reverting to the platform identity and releasing a claimed subdomain remain available, so losing a capability never traps the organization on a hostname it cannot manage.

Branding is organization-scoped. Switching organizations switches the product name and appearance with it, and sign-in links on a branded host still resolve the correct organization before a session exists.

When payment lapses

The app becomes read-only. It never locks you out.

Every read keeps working, including the ones your plan gates — so the data stays reachable and exportable while the payment is sorted out. Mutating requests are refused, with the exception of the billing screens themselves and leaving the organization, because a refusal that blocks the fix is worse than useless.

An organization that has never subscribed has full access. Free is a real state, not an unpaid one.

Restricting changes by source address

A project can declare a set of allowed source addresses and name which kinds of change — deploy, destroy, provisioning, and so on — are restricted to them. A request from any other address is refused, with a message naming the fix rather than a bare denial. A separate policy at the organization level covers the handful of routes that name no project at all, such as changing a member's role or deleting the organization itself.

Nothing is gated until you configure it, and the two levels never overlap: a route governed by one is never checked against the other. CI and other automation authenticating by workload identity are exempt by design — narrower ranges than a whole hosted-runner pool would either lock out every pipeline or be too broad to mean anything — and that exemption is itself visible on the policy screen rather than a silent carve-out.

This is an application-level check, not a network perimeter: it does not replace a security group, a resource policy, or a WAF rule in front of the API, and it never restricts what you can read — only what you can change.

Deleting an organization

Only the owner can, and it cannot be undone. The confirmation asks you to type the organization's name.

What matters is the report it returns afterwards, which is shown on screen and can be copied: three things outlive a tenant and each fails silently if left behind — a provider credential still held, infrastructure still being billed (listed, never destroyed — this platform does not delete your cloud resources), and an uncancelled subscription. Copy the report before dismissing it; there is no tenant left to read it from afterwards.