Access and roles

Everyone in Adea has one of three roles. The role decides what a person can change. Access rules decide which of your data a person’s questions can use.

The three roles

	Member	Developer	Administrator
Ask questions, save them and build dashboards	Yes	Yes	Yes
Read insights and work through lists	Yes	Yes	Yes
Connect databases and code		Yes	Yes
Correct what Adea understands about your data		Yes	Yes
Send a developer link		Yes	Yes
Create API keys		Yes	Yes
Invite people and change roles			Yes
Set access rules, sign-in rules and your brand			Yes
Create and switch off public links			Yes
Plan, billing and the data processing agreement			Yes
Approve or decline what Guardian holds			Yes
Export everything, or delete the company			Yes

Whoever creates the company is its first administrator. Give most people the Member role, your developers the Developer role, and keep the Administrator role for the few who run Adea.

Invite a person

1. Open Settings, then Team.
2. Enter the work email, choose Member or Developer, and send the invitation.
3. The person gets a mail with a link that works for 14 days, signs in and joins.

You can send the link again, which stops the earlier one, or cancel the invitation. To make someone an administrator, change their role in the team list. A second administrator has to approve that, or it takes effect after 24 hours, so one stolen account can’t hand out control. There always has to be one administrator, and you can’t change your own role.

How people sign in

A person signs in with a link sent to their email, a passkey, Google or Microsoft. Each person can add a passkey under Settings, then Profile and preferences.

On the Business plan an administrator can require sign-in with Google, with Microsoft, or with either. Adea refuses the change unless the administrator can sign in that way themselves, and tells them how many colleagues still need to. This is a rule about which accounts are allowed, not a link to your company’s own single sign-on.

Take a person out

Remove a person under Settings, then Team. Their access ends at once, and so do their API keys and every AI assistant they had connected.

Limit what a person can see

On Pro and Business an administrator can set rules for each role under Settings, then Access:

• Hide a table or a column. The role can’t use it at all, not even inside another question.
• Mask a column. The role can count and group by it, but its values show as ••••.
• A rule in plain words, such as “Only administrators see salaries”. Adea follows it as well as it can, but use a hidden or masked column when you must be sure.

The same page shows who sees what, by table, for every person and every connected AI assistant, so you can check a rule did what you meant.

If you move to a plan without access rules, the rules you already have keep working, but you can’t add new ones.

Give a person one location

On Pro and above an administrator can limit a person to a part of the business, such as one location or one team. Their Home, insights, lists and briefing then follow only that part. The choice appears under Settings, then Team, once Adea finds a location or a team in your data. See Invite your team.

AI assistants and Slack

An AI assistant works as the person who connected it, with at most that person’s role and rules, and every call is logged in their name. Questions from Slack follow the same rules. See Use Adea from your AI assistant.

Keys for your own tools

An API key acts as the person who made it, with at most their role. Members can’t make keys. See The API.

What an administrator sees

Guardian keeps a log of what was asked and what it decided, which administrators can read under Settings, then Guardian. See Guardian and security.