Projects and who can see them

When a new teammate signs in for the first time and the app looks empty — or they see the message “You don’t have project access yet” — nothing is broken. Two separate things decide what a person can see in Routario, and a brand-new account has only cleared the first one.

This page explains both, so you know exactly what to grant and where.

Two questions, two roles

Every account is checked against two questions:

1. Can they sign in at all? — their workspace role.
2. Which of your data can they open? — the projects they belong to.

Workspace role is either Administrator or User:

• An Administrator runs the workspace. They can do everything and can see every project automatically — you never add an administrator to a project.
• A User is a regular teammate. They can sign in, but they see only the projects they’ve been added to.

Projects are the spaces your work lives in — the data, records, and tools a group works with. A User is placed into one or more projects, and that decides what appears when they sign in.

This is a different layer from Settings → Access

Belonging to a project decides which project’s data a person reaches. What they can then do inside it — see Deals, write to Memory, arm a Flow — is a separate, finer setting covered in Access: who can do what. Think of projects as the room you’re let into, and Settings → Access as what you’re allowed to touch once inside.

“You don’t have project access yet”

If a User hasn’t been added to any project, Routario doesn’t drop them into an empty, confusing app. It shows a clear screen:

You don’t have project access yet. Your account is active, but not assigned to any project. Projects group the data and tools you work with. Until an administrator adds you to one, the app has nothing to show.

That’s the normal state for a freshly created teammate. It clears the moment an administrator adds them to a project — no new sign-in needed, just a refresh. Administrators never see this screen, because they’re in every project by default.

Most workspaces have just one project

By default a workspace has a single project (“Default Project”). When there’s only one, projects stay out of the way entirely — there’s no project switcher, and most people never think about them.

But the one project still has a member list. Adding a teammate to your workspace does not put them into that project automatically — you add them to it as a separate step. If you skip it, they’ll land on the “no project access” screen above. So even on a one-project workspace, the rule holds: a User has to be added to the project before they can see anything.

When you have more than one project

Projects earn their keep once your work splits into groups that shouldn’t mix — separate clients, branches, or teams that each need their own data kept apart.

• A teammate can belong to some projects and not others, so they only ever see what’s theirs.
• When someone has access to more than one, a project switcher appears in the sidebar so they can move between them.
• Within a project, a member holds a project role — User (work in the project), or Manager / Approver for people who take on extra responsibilities like approving actions. The role is set per project, so the same person can be a plain User in one project and an Approver in another.

Who can change this, and where

Managing roles and membership is an Administrator job. There are two things to set, in two places:

• Workspace role (Administrator or User) — chosen when you create the person, in Settings → Users.
• Project membership (and their project role) — in Settings → Projects: open a project, go to Members, and add the person with a role. There’s also a quick add-to-project action on someone’s row in Settings → Users, for the common “this new teammate should see the main project” case.

A worked example — a new teammate who should work in your main project:

1. Settings → Users → create them as a User (not Administrator).
2. Settings → Projects → open the project → Members → add them as User.
3. They refresh, the “no project access” screen is gone, and they see the project.

Skip step 2 and they’ll be stuck on the no-access screen — a quick fix once you know to look for it.

Self-hosting?

If you run Routario yourself, the same membership change is available from the command line: routario project add-member <username> adds someone to the default project, with --role and a project name for anything more specific.

Where to go next

• Access: who can do what — the finer layer: what a person, agent, or key can do inside the areas they reach.
• Give a teammate or agent the right access — the click-path for the access matrix.
• Manage your sign-in security — passwords and two-factor for the people you’ve added.