Inviting the client's owner

A client workspace can't publish a survey until somebody at the client is an owner. This is the one rule the practitioner setup adds, and it exists to protect the client rather than to police you.

#Why publishing waits

The key that decrypts a workspace's results is held by its people, not by us. If you're the only person holding a client's key, then when the engagement ends the client has a workspace full of ciphertext and no way in. They paid for those results and they'd lose them.

So: draft, author, import questions, invite recipients, set everything up. All of that works with only you present. Publish is where an owner from the client becomes a requirement, because publish is the moment after which real answers exist.

If you try before then, you're told "Invite an owner from the client before you publish. They need their own key, or the results go with you when the engagement ends."

#Inviting one

Go to Admin → Users in the client's workspace. The Engagement access card at the top has the form. Until someone from the client is an owner, it also says "Nobody from your side is an owner yet".

1. Enter their email. Under Invite an owner from your organisation; the person who'll own this at the client. Someone in HR, People or Legal, usually; the person who'd still be there after you leave. A name is optional.
2. Invite owner. What happens next depends on whether they already have an InviziPoll account.
3. They accept. If they were sent an invitation, they set up their account and become an owner. If they already had an account, they're an owner immediately.
4. Restore their key. Once they're in, they choose Ask an owner to restore it and read you the code on their screen, by phone or in person. Type it under Access requests from your team on your Approval Queue page and choose Restore access. Until then their row says "No key yet": they can open the workspace, but results stay sealed to them.

An owner can restore a colleague's access only after confirming a code with them directly; we can't do it for them. Don't accept the code by email or chat. See Restoring a teammate's access.

#What the client's owner can do

Everything an owner can do in any workspace: run surveys, read results, manage people, take over billing, and end your access. That last one is the point. Their control over the engagement shouldn't depend on your goodwill.

#Ending access

While the workspace is sponsored, any owner can end a consultant's or an invited person's access from the Engagement access card with End access. Doing so revokes the membership and deletes that person's stored copy of the workspace key, so the next request is refused and the next key fetch finds nothing.

It can't reach into a browser that has already unwrapped the key. That's the same honest limit removing any collaborator has always had, in this product and in every other one that does client-side encryption. What it does guarantee is that nothing new is decryptable and no new session gets in.

The card only shows while the workspace is sponsored. After the client takes over its own subscription it's gone, and there's no button in the app to end your access from then on. If the client wants your access ended at the handover, do it from the card before they take over billing.

#Who is who on the roster

The Engagement access card labels each person by where their access came from:

• Consultant: you and anyone at your firm, added under the engagement. A client's directory sync will never add or remove these.
• Client: their own people, whether they signed up here or were invited.
• Client directory: provisioned by the client's identity provider.

That distinction matters to a client's IT team: a consultant's access is deliberately outside their automated provisioning, so it's visible on this page rather than invisible in a sync.

#Related

• Creating a client workspace
• What a sponsored workspace means
• Handing a client its own subscription