Members and access

Getting people in

People join an organization one of three ways: you invite them, they sign in through your identity provider, or they join automatically because their email is on a domain you have verified.

Joining and signing in are separate questions. However someone joined, they can sign in with a Google account, with an email and password, or through your own directory once you connect it.

Invitations are managed at the organization, and an invitation carries a role. That role is the person’s role everywhere, so it is worth a moment rather than a default: what they can reach afterwards is decided by which factories you put them on. See roles and permissions for how the two combine.

An invitation is for the address you sent it to, and only that address. Forwarding one does not pass it on: whoever opens the link has to be signed in as the person invited, or it is refused. If you invited the wrong address, revoke it and send another rather than asking someone to forward it.

Verified domains

Verifying a domain lets anyone with an email address on it join without an individual invitation.

You add the domain, publish the DNS record Taiga gives you, and then verify it. The DNS step is the point: it proves you control the domain, which is what stops someone else claiming your company’s email addresses.

Verification is what switches this on, and nothing else does. An unverified domain matches nobody, including the one recorded from your own email address when the organization was created. Adding and verifying domains is an administrator action.

Someone joining this way is offered the organization when they sign up rather than being placed in it silently. What they get is fixed: the member role and your organization’s default factory. There is no approval step and no way to vary either at the door, so anyone who joins this way arrives able to do member things in whatever that factory can reach.

Weigh that before turning it on. For a company where everyone with a work address should have access, it removes an administrative queue. For one where access is deliberately narrower than the payroll, invitations are the right mechanism and domain join is a hole in it.

Single sign-on

Two different things go by this name, and only one of them is yours to control.

Continue with Google is always available, on every sign-in page, to anyone with a Google account. There is nothing to configure and nothing to switch off. It works before Taiga knows which organization you belong to, which is exactly why it is offered first.

Your own directory is the one you connect. Taiga supports Microsoft Entra ID, and connecting it takes your Azure directory (tenant) ID. Entra is the only directory you can connect today.

The difference that matters is control. A connected directory is yours: you decide who is in it, sign-in follows your rules, and you can make it the required route. The Google button is not.

Verify a domain first. A directory is connected against a verified domain, so the previous section is a prerequisite rather than a parallel feature.

Once connected, sign-in adapts to the email address: a user on your domain is taken to your directory instead of being shown a password field.

Connecting SSO does not by itself close the other doors.

Require SSO blocks password sign-in for your members on that domain, so nobody keeps a separate Taiga password to guess at.

Owners are the exception, and permanently. An owner can always sign in with a password, by design, so a broken SSO configuration can never lock the organization out of itself. Everyone else, admins included, is subject to the requirement, which is the thing to be careful about: enable it once you have confirmed SSO works.

Members of an SSO-enforced organization see a sign-in page that offers only that route, and are told plainly that their organization requires it rather than being left to work out why their password stopped working.

For how authentication is implemented rather than how you configure it, the trust centre covers identity, isolation and access.

Two-factor authentication

You can require two-factor authentication for everyone in the organization.

The decision that matters is the rollout, not the requirement. You can enforce it immediately, or give members a window of a week, a fortnight or a month to set it up.

Immediate enforcement locks out everyone who has not already enrolled, which on a working day means everyone. A window lets people enroll on their own time and still ends with the same policy. Choose immediate only when you are responding to something.

Accounts that came in through your identity provider delegate this to it. Taiga does not ask them to enroll separately, because the check has already happened and asking twice would be theatre.

The line is where the account came from, not how someone signs in day to day. Signing in with a Google account is a convenience, not your directory, so it does not exempt anyone: those accounts enroll in Taiga like password accounts do.

Members enroll from their own account settings.

Sessions

You set a maximum session length for the organization: how long someone can stay signed in before they have to authenticate again.

This is the control that turns an unattended laptop from an indefinite problem into a bounded one. Pick the shortest length your people will tolerate.

You can also sign a specific user out of all their sessions immediately. That is the right response to a lost device. It is not a punishment and not a removal: they can sign straight back in.

Put people on a factory when you invite them

An invitation carries the role, which says what someone can do. It also carries their factories, which say where.

Pick the factories in the invitation when you know them, since that is the cheaper moment. If you pick none, they join your default factory, which is the same place people who join by email domain or single sign-on land. Nobody arrives able to reach nothing.

That default is a floor, not a filing decision. Someone who should be on a specific factory is easier to place now than to find later.

Creating factories and managing who is on them is an administrator action.

When you create one, the question is not which department it represents. It is which products these people should reach, since that is the only thing factory membership decides.

Removing access

Removing someone from a factory removes their access to that factory’s products, except a product they created, which they keep as its direct member. Their account, role and sessions are untouched.

Removing them from the organization deactivates the account, and signing them out of every session is part of the same act, so the removal takes effect immediately and there is no second step to remember.

Deactivation keeps the account and its history rather than deleting them, and it can be reversed. That is what you want when the removal was a mistake, and no obstacle when it was not.