Users, roles, licenses, and teams

Add and remove users, assign roles and licenses, fine-tune per-user rights, group users into teams, and control who sees what.

In Settings > Company settings > Users and Teams you control everyone who can sign in to your Reonic workspace and exactly what they can do. Access is composed from several layers: the areas your workspace includes, the user's per-area access, their role (Viewer / Editor / Admin), and a set of fine-grained rights. That lets you build setups from "every installer can edit everything" to "this sales rep sees only their own leads and can't change prices."

Before you start

You need the Admin role to manage users. Editors and Viewers can't open this page. The Settings tab doesn't appear in their navigation.
Decide each new user's role (Viewer / Editor / Admin). This is the broad capability tier and the hardest layer to override later.
Decide whether they need a license (paid seat). Many workspaces rely on role plus area access alone. Where licenses are used, the available types depend on what your workspace includes, and new licenses are arranged with your Reonic account manager.
For partners or sub-contractors who should only see specific projects, plan to use the External user flag rather than a full Editor seat.

Open the Users and Teams page

Click Settings at the bottom-left of the Portal.
Choose Company settings > Users and Teams.
The page opens on the Users tab. Each row shows a user's name, email, role, license, and rights at a glance.
Switch to the Teams tab to manage team structure (covered further down).
Click a user row to open their detailed permission panel.

Note: If you can't see Settings at all, your role is below Admin or your account is missing the Settings area access. Settings appears when your role is Admin or higher and Settings access is on for your account. Both are set on the same user-permissions screen. Ask your workspace owner to raise your role and grant Settings access.

Invite a new user

Open the Users tab.
Click Add user (top-right).
Fill in the user's details:
- Email address is required. This is the sign-in identity and where Reonic sends the welcome link.
- First and last name are recommended. They appear on offers as the processor contact.
- Phone is optional, and shown on offer PDFs if filled.
Pick a role: Viewer, Editor, or Admin.
Optionally tick External user if this person should only see projects explicitly assigned to them (typical for sub-contractors, financing partners, regional installers).
(If your workspace uses licenses) assign a license from the available types.
Click Save. Reonic sends a welcome email with a sign-in link to the address you entered. On first sign-in the user joins your workspace.
After saving, configure Area access and Individual rights in the user's detail panel (see the next sections).

The new user clicks the link in their welcome email, lands in the Portal signed in, and is ready to work. Reonic uses passwordless sign-in, so there's no password step (see Sign in to Reonic below).

Pro tip: Set the role, license, and rights before you click Save. Adjusting them later works, but if the user is already signed in, their access shifts live, which can be confusing mid-session.

What the invited user sees

The welcome email arrives within about 30 seconds, with a subject like Welcome to Reonic. The user opens the email, clicks Sign in to Reonic (or the long link underneath if the button doesn't open), and lands directly in the Portal. No password to set, no extra step.

If the email doesn't arrive:

Check spam / junk. First-time recipients sometimes get filtered. Mark Reonic's mail as not-spam to fix future delivery.
Verify the email address you entered. A typo here is the most common cause.
Have the user request a fresh sign-in link themselves from the Portal sign-in screen (see Resend a welcome link below).
If still no email, contact Reonic support.

Add multiple users

Each user is invited individually. For a 10-person onboarding, budget about a minute per user: fill in email, name, role, license, save, repeat.

The three user roles

Reonic has three roles you can assign in the Portal. In ascending order of capability: Viewer > Editor > Admin.

Viewer

Read-only. A Viewer sees the areas you grant them but cannot create, edit, complete, or delete anything. Good for:

IT or accounting auditors who only need read access.
Field workers who only consult schedules and photos.
Anyone you want to onboard before deciding their final scope.

Note: A Viewer can read the calendar but cannot set or edit appointments. If they need to manage their own schedule, promote them to Editor.

Editor

The standard "does the work" role, where most of your team lives. Editors create, edit, complete, and assign almost everything outside Settings:

Leads / requests: create, edit, complete, assign, and move a request to offer (needs the Convert request to offer right).
Offers: create, edit, send offers and variants, add line items, customise PDFs per offer, and sign offers on behalf of the customer in person. Editing prices needs the Edit prices right; applying discounts needs the Apply discounts right.
Installations (residential and commercial): create, edit, complete, move offers to installation (needs the Convert offer to installation right), and manage checklists, file requests, calendar invites, and photos.
Invoicing (with the Issue invoices right): create, edit, issue, and send invoices; partial invoices and credit notes; mark paid / partially paid / uncollectable.
Customer portal: activate / deactivate per project, request files, send portal links.
Tasks, calendar events, notes, files, the AI-chat assistant, voice transcription, and photogrammetry (with the Create photogrammetry jobs right).

Settings-level actions are reserved for Admin: opening Settings, managing other users, editing workspace branding, configuring PDF or email templates, setting default energy prices, and connecting integrations. No individual right overrides that role floor. Giving an Editor Issue invoices lets them issue invoices; it does not let them configure invoicing settings (that's Admin-only).

Administrator

Full access, including Settings, user management, integrations, branding, PDF templates, and email templates. Admins also see purchase prices and margins, and hold every individual right by default.

Reserve Admin for people you'd trust to lock you out of your own workspace. They can demote you, change your role and rights, or remove you from the workspace. Always keep at least one Admin in the workspace, and promote a replacement Admin before removing or demoting the outgoing one.

Pro tip: A typical 10-person installer org has 1 to 2 Admins and 7 to 8 Editors. Resist the urge to make everyone Admin. The role floor is what stops accidents.

External user

External user is a flag you can tick alongside Viewer or Editor. It's not a fourth role. When the flag is on:

The user only sees projects they're explicitly assigned to (as Key Account, additional user, or team member where they lead the team).
They have no Settings access, no global lead list, and no cross-project search: a deliberately stripped-down UI.
They still need at least Viewer (to read) or Editor (to edit) on those assigned projects.

Use External user for financing partners, sub-contractors, or regional installers who should not see your full pipeline. Plan their per-project assignments deliberately: External user has narrow defaults by design.

Note: Admins are always full-workspace, so the External user flag doesn't apply to them.

Assign a license

A license is a paid seat. Not every workspace uses licenses. If you don't see a License section on the user, your workspace doesn't gate by license, and role plus area access alone decide what users can do.

Where licenses are used, the available types are:

Residential Collaborator: for users who plan, sell, or install residential projects (heat-pump, PV, wallbox).
Commercial Collaborator (the Gewerbelizenz in German workspaces): for users who handle commercial / B2B projects. Assign it to anyone planning or selling commercial offers. It also covers installation, so the same seat handles commercial install work.
Residential Installer: the installation-only license, for field workers who don't plan or sell. This is the only installation-only seat.
Viewer: a read-only seat.

Note: For commercial / B2B installation work, use the Commercial Collaborator license, which already covers installation. There's no separate commercial-installer seat.

To assign:

Open the Users tab and click a user row.
In the License section, you see the licenses currently available (for example, "2 Residential Collaborator seats free").
Click the license type you want to assign.
Click Save.

The user can now access the areas covered by that license. To revoke, clear the license selection on the same screen.

Buy more licenses

License purchase is handled by your Reonic account manager. For the full walkthrough on buying, returning, and reviewing licenses, see Manage your Reonic licenses and subscription invoices.

Revoke and reassign a license

Open the user row whose license you're freeing.
In the License section, clear the assignment.
Click Save. The seat returns to your available pool.
Open the new user's row and assign the license there.

The first user keeps their role and rights. They just lose access to license-gated areas until you re-assign. Licenses are seat-based, not usage-based, so removing the license (or the user) frees the seat immediately.

Note: If revoking a license seems to fail (the seat doesn't free up), the most common cause is the user still has active work blocking the revoke, such as an open offer they're editing. Wait a few minutes and try again, or contact support.

Control area access

After assigning a license, you set which areas the user can reach: typically Requests, Offers, Installations, Components, and Settings (for Admins).

Open the user row.
In the Area access section, tick the areas this user should reach.
Click Save.

What's available depends on the license:

Residential Collaborator: Requests, Offers, Installations for residential.
Commercial Collaborator: the same, for commercial.
Residential Installer: Installations only.
Viewer: read access to the assigned areas.

For Residential licenses, you can additionally grant Components and Settings if you want this user to manage your component catalog or workspace configuration.

Pro tip: Withhold Components and Settings from brand-new Editors until they're trained. Edits there can cascade across every offer in the workspace if mis-applied.

Grant the Installations area to another user

The Installations tab is controlled by a per-user area toggle, not by an individual right. Residential and commercial installations have separate toggles, so you can let someone see residential installs while keeping commercial hidden, or vice versa.

Open the user row.
Under Area access, tick Installations, choosing the residential and/or commercial toggle as needed:
- Residential-only field worker: residential on, commercial off.
- Back-office user tracking both lines: both on.
- Sales-only role: both off (the Installations tab disappears from their nav).
Confirm the user has a license that includes installations (Residential Collaborator or Residential Installer for residential; Commercial Collaborator for commercial).
Click Save. The Installations tab now appears in their navigation.

Note: The area toggle is necessary but not sufficient. To actually move an offer into the installation phase, the user also needs the Convert offer to installation individual right, and your workspace has to include installations.

Grant the invoicing right

Invoicing is a separate individual right (see below), not an area toggle.

Open the user row.
In the Individual rights section, tick Issue invoices.
Click Save.

If invoicing still doesn't appear, confirm that Invoicing is enabled on your workspace and the user has access to the Offers area (invoices fork off offers).

Grant individual rights

Below the area toggles is a list of individual rights (about 20 in total): fine-grained switches that gate sensitive actions on top of the role. Most default off; the one exception is Plan permission service (request planning service), which defaults on for Editors. For Editors, you can tick:

Assign users and teams to projects.
Convert offers into installation projects.
Convert requests into offers.
Edit prices on offers.
Edit purchase (buy) prices on planned components. This is a dependent right: you can grant it only to someone who already has Edit prices. It lets you allow sell-price edits while keeping your purchase (buy-in) prices hidden from that user.
Apply discounts.
Issue invoices.
Create custom components.
Create photogrammetry jobs.
Request grid registration.
Request subsidy filings.
Manage project folders.
Create procurement orders.
and a handful more, depending on what your workspace includes.

Each right shows an info icon explaining what it covers.

For Administrators, these toggles are greyed out: Admins have every individual right by default. For Viewers, only read-related rights matter.

Note: Some rights appear only once the matching capability is available in your workspace. The Apply for on-site service (Baustellenservice) right, along with Request grid registration, Oil tank removal, and Order smart meters, show up in this list only once their underlying feature is available. If you expect a right and can't find it, contact your account manager; once the capability is available you can grant the right per user.

Pro tip: Build "patterns" for common roles: - Junior account manager: Editor + Convert request to offer on, Edit prices and Apply discounts off. - Senior account manager: Editor + most rights on. - Finance / billing point: Viewer + Issue invoices on. They see everything read-only but can manage invoices end-to-end. - Sales-only role: Editor + most rights, except Issue invoices (handoff to finance after signature).

Hide prices from a user

To stop a user from changing prices on offers, untick Edit prices in their Individual rights. They keep the rest of their workflow, but the price fields lock for them.

To hide prices from view as well, set the user to Viewer and remove the Edit prices right. They can still see offers, with pricing fields read-only. Pricing is controlled at the right and role level rather than per individual field.

To let someone edit sell prices while keeping your purchase (buy-in) prices out of reach, leave Edit prices on and withhold Edit purchase (buy) prices (see Grant individual rights above).

Note: VAT is a special case. Setting the VAT rate on an offer normally needs the Edit prices right, like any other price field. Your Reonic account manager can loosen this for the VAT field only, so that any Editor can set VAT rates without holding Edit prices. If a user can change VAT but not other prices, that setting is why; every other price field still needs the right.

Restrict component editing

To stop a user from creating custom components, untick Create custom components.
To restrict the Components area entirely, untick it under Area access.
To let them use components someone else creates without modifying the catalog, leave Components access on and untick Create custom components.

Restrict archiving

Editors can archive projects they have access to, and Viewers cannot. Archiving follows the role rather than a separate right, so to prevent a specific user from archiving, set them to Viewer on the projects you want protected.

Save changes to rights and licenses

After toggling rights or assigning a license, click Save at the bottom of the user panel. Changes apply on the next action the user takes; they don't need to sign out and back in.

If the user is mid-task when you revoke a right, their next save shows a permission message and they may need to refresh.

Change a user's email address

A user's email is their sign-in identity, and it's fixed once the account is created. It cannot be changed in-app, by the user or by an admin. There's no editable Email field on the user row.

To move a user to a different address:

Create a new user under the new email (Add user), reassign the old user's projects, Key Account ownership, and team memberships to it, then remove the old user. Their past activity stays attributed to the old account.
Contact Reonic support to change the address on the existing record. This keeps the user's projects, assignments, and history intact, and is the better route when preserving the same user matters.

Note: If the old email feeds external integrations (inbound lead routing, your accounting system, Zapier triggers), update those separately. Reonic doesn't auto-rewrite external mappings.

Change a user's name, phone, or title

An admin can't change another user's name or phone. Only the user can, on their own profile. Ask the user to update their own details (see Manage your Reonic user profile for the self-service walkthrough on name, phone, picture, language, and notifications). If they genuinely can't, contact Reonic support.

The phone shown on offer PDFs as the processor contact is the user's own profile phone, not a separate "offer contact phone" field. When that user updates it, future offers reflect the new number; existing offers stay pinned to the value at offer-creation time.

Edit your own profile

For the full self-service walkthrough on editing your own name, phone, picture, language, notification preferences, and the CC me on offer-sent emails toggle, see Manage your Reonic user profile.

Remove or deactivate a user

Open the user row of the person leaving or no longer needing access.
Click Remove from workspace.
Confirm. The user loses access to this workspace; their historic actions and the projects they touched stay attributed to them.

Removal is per-workspace: it only affects your workspace. The user's Reonic identity and any seats they hold in other workspaces are untouched, so they can still sign in elsewhere. So:

Removing a user is the right move when they leave your company but might still belong to another installer's Reonic workspace later. Their account stays alive, just not in your workspace.

Note: Always promote a replacement Admin before you remove or demote the outgoing one, so the workspace keeps at least one Admin who can open Settings.

What happens to their data

Projects, leads, offers, invoices the user created stay where they are, keeping the historical author attribution.
Assignments to active work don't auto-transfer. Re-assign Key Account, project members, and team assignments to other users yourself.
Tasks assigned to the removed user remain on the project; reassign them via the task panel.
Calendar entries they created stay; their team calendar stays with the team.
Access ends when they're removed from the workspace: the next time they try to use Reonic on any device, they no longer have access.

Sign a user out of all devices

To end a user's access on every device, remove them from the workspace on their user row (Remove from workspace). The next time they try to use the Portal or Mobile App on any device, they no longer have access. Re-add them later if they need to return.

Audit who has access

To audit access, review the Users list: anyone with a row plus a valid email can sign in.

Resend a welcome link

If an invited user never received their first email or lost it, you don't need a special resend. Because Reonic is passwordless, they can get a fresh sign-in link any time, themselves:

The user opens your Portal URL and enters their email on the sign-in screen.
They click Send magic link. Reonic sends a fresh link plus a one-time code.
They click the link (or type the code) and they're in.

Have them check spam first. If the link still doesn't arrive, confirm their email is spelled correctly on the Users page, then contact Reonic support.

Reonic is passwordless. Every sign-in uses an email-based link. On the Portal, that's a magic link or a one-time login code by email (and by WhatsApp where that's configured), plus SSO where enabled. On the Mobile App, it's a magic link or one-time code by email (and by WhatsApp where configured), a QR-code scan from a signed-in Portal session, or SSO where enabled.

Open app.reonic.de (or your country-specific Reonic Portal URL).
Enter your email address on the sign-in screen. There's no password field.
Click Send magic link.
Check your email. The message arrives within about 30 seconds.
Click Sign in to Reonic in the email (or the long link underneath if the button doesn't open). The browser opens the Portal signed in.

Your session persists across refreshes. Next visit, you're signed in automatically if your session is still active.

Open the Reonic Mobile App.
Enter your Reonic email.
Tap Send. The app sends a magic link plus a one-time code by email (and by WhatsApp, if your workspace has the WhatsApp Assistant enabled and a verified number).
For the magic link: open the email on your phone, tap the link, and the app opens signed in.
For the one-time code: type the code from the email (or WhatsApp message) into the app.
For SSO users: entering an SSO-tied email sends you to your provider's sign-in page in the system browser, then returns you to the app.
Alternative, QR-code sign-in: scan the QR code in Profile > Mobile sign-in of a signed-in Portal session to skip the email round-trip.

When the magic-link email doesn't arrive

Check spam / junk. First-time recipients often see Reonic emails filtered. Mark as not-spam to fix future delivery.
Verify your email. A typo here is the most common cause.
Wait about a minute, then click Resend magic link.
Ask your admin to confirm your account exists and is active in the workspace.
Contact Reonic support if the email truly never arrives.

Note: If a sign-in link stops working, request a fresh one from the sign-in screen. Signing in proves you control the email account, so keep that email account well protected.

Magic-link email is universal, and the Portal also offers a one-time login code by email (and by WhatsApp where configured). Keep the email account you sign in with well protected, and use SSO if your organization prefers a central identity provider.

If your organization mandates SSO, Reonic supports it via OIDC (OpenID Connect). Ask your Reonic account manager to set it up. Once it's on, the sign-in screen shows a "Sign in with [provider]" button, and SSO works on both the Portal and the Mobile App (identity providers like Okta, Google Workspace, or Azure AD).

Switch between workspaces

If you belong to multiple Reonic workspaces (for example, you're Admin in one company and Account Manager in a sister company):

Click your avatar / profile icon in the top-right of the Portal.
A workspace switcher lists every workspace you belong to.
Click the target workspace. The Portal reloads with that workspace active.

Your role and rights are workspace-specific: you might be Admin in one and Viewer in another. The role you see is whichever workspace is currently active. One email maps to one Reonic user, and that user can belong to multiple installer companies. Each workspace is operated independently after switching, and projects, offers, and customers stay scoped to their own workspace.

Manage multiple sub-accounts as a parent admin

The same workspace switcher applies: switch in, do your work, switch out. For larger multi-entity setups, contact your account manager about agency / parent-account features.

Demo or training workspaces

For a sandbox to train new sales reps, ask your Reonic account manager. They can set up a training workspace or a sandbox mode for you.

Manage teams

Teams group users together (for example, Sales team Berlin, Installation crew north). Teams matter for two reasons:

Visibility for external users. When you assign a team to a project, team leaders see the project; team members do not see it automatically. This lets you model classic sales structures where leads aren't shared across all reps.
Bulk assignment and a shared team calendar. Assign a whole team to a project or task in one click; every team gets a 1:1 team calendar created automatically.

Teams live alongside Users in Settings > Company settings > Users and Teams under the Teams tab. Every team has a name, an optional description, leaders, members, and an automatically-created team calendar.

Note: If you don't see the Teams tab in Settings, either Teams isn't enabled for your workspace (contact your account manager) or you're not an Admin (Editors and Viewers see only the Users tab and cannot manage team structure).

What teams are (and what they aren't)

Teams in Reonic are a lightweight user-grouping primitive, not a full org-chart-with-roles surface. The mental model:

A team is a named group of users within your workspace.
Each user can belong to multiple teams at once. There's no "primary team" concept.
Each team has a mix of leaders (visibility on assigned work) and members (no auto-visibility).
Teams support a parent / sub-team tree for hierarchical structures (regional manager > city crews).
Each team gets an auto-created team calendar when it's first created.

What teams are not:

Not a fourth user role. Roles (Viewer / Editor / Admin) and the External-user flag live on each user individually. Teams add a layer on top of roles; they don't replace them.
Not a custom-permission engine. Per-user rights and the External-user flag remain the granular levers. To give "team X" a capability, you set it on each user.
Not shared across workspaces. Each Reonic workspace has its own teams. A user who belongs to two workspaces has separate team memberships in each.
Admin-managed. Team membership is admin-set: a user is added or removed by an Admin, not by self-join.

Open the Teams tab

Click Settings at the bottom-left of the Portal.
Choose Company settings > Users and Teams.
The page opens on the Users tab. Switch to the Teams tab to see the list of teams in your workspace.
Each row shows the team name, the number of leaders, the number of members, and the team description if set.
Click a team row to open its detail view: leaders, members, sub-teams, and calendar settings.

Create a team

Open Settings > Company settings > Users and Teams > Teams tab.
Click Create team (top-right).
Enter a name, short and descriptive. Common patterns: Sales team Berlin, Installation crew north, Planning team, AC installers.
(Optional) Enter a description to clarify scope ("All sales reps in Berlin region + their team lead"). The description appears on the team's detail page and in pickers.
(Optional) Pick a parent team if this team belongs under another (see Nested teams below).
Add users. Search by name or email, and for each user pick Team leader or Team member (radio toggle next to their name). Repeat for everyone who should be on the team.
Click Save.

The team is now live. The team calendar is auto-created, and the team appears in pickers for project assignment, task assignment, file folder sharing, and wiki page sharing.

Pro tip: Decide the leader / member split before you create. It's the single most important configuration choice on a team. Leaders see assigned work; members do not auto-see it. The split is a permission lever (especially for External users), not a title. You can change it later, but the split drives visibility from day one.

Note: The membership picker accepts everyone in your workspace, including External users, Viewers, and Admins. The leader / member split applies to every team member regardless of role. An External user as Team leader will see assigned work; an Admin as Team member won't gain visibility from the team (although Admins typically see everything via their role anyway).

Add and remove team members

Team membership is editable on the team's detail page at any time. Changes apply immediately.

Add a member to an existing team

Open Settings > Company settings > Users and Teams > Teams tab.
Click the team's row to open its detail page.
Click Add member (or + Add user).
Search by name or email.
Pick Team leader or Team member for the new user.
Save.

The new user picks up team visibility (if leader) and the team calendar immediately. Adding someone to a team doesn't send them a notification, so tell them out-of-band if it matters.

Remove a member from a team

Open the team's detail page.
Find the user's row.
Click the × or Remove action next to them.
Save.

The removed user loses team-derived visibility immediately. Any work they could see only because they were a leader on this team is now hidden. Work they have direct access to via their role, Key Account assignment, or project-user assignment is unaffected.

Promote a member to leader (or demote a leader to member)

Open the team's detail page.
Find the user's row.
Toggle their role between Team leader and Team member.
Save.

Promoting a member to leader expands their visibility on assigned work immediately. Demoting a leader to member narrows it. Think of the toggle as a quiet permission lever, useful when an installation lead joins a sales team to oversee handover during a multi-stage project.

Pro tip: A user can be a leader in one team and a member in another. There's no notion of "global leader"; the split is per-team. If your regional manager leads three city crews but is just a member of the head-office team, that's exactly how you'd configure it.

Team leader vs team member, the visibility rule

The split matters as soon as you assign the team to a project, offer, request, file folder, or wiki page:

Team leaders automatically see assigned projects and offers. They can open the entity, edit it (within their role limits), and re-assign work to specific members.
Team members see team assignments only when they have a separate path: Key Account, individual project-user assignment, or non-External role-based access. Add them individually as project users if they need access from the team assignment.

For internal users (Viewer / Editor / Admin without the External flag), the team-assignment rule is largely moot. Internal Editors and Admins already see all projects in the workspace, so the leader / member split mainly narrows things for External users, where the flag turns it into a hard visibility gate.

How this looks in practice, two team archetypes

Sales team, one leader, the rest members.

The team lead is the only one who sees incoming leads automatically. They triage and re-distribute manually, assigning each lead's Key Account to the specific rep they want. Members see leads on their own assignments. This models the classic "no leaderboard / no lead-stealing" sales structure where the manager controls intake.

Installation crew, everyone a leader (there's no per-team limit on leaders).

Every crew member sees assigned installations. There's no triage step; every project on the team is visible to every crew member, which is what you want for cooperative on-site work. The team functions as a flat working group.

Pro tip: Promoting a member to leader is one click, and the next time you assign a project to that team, the newly-promoted leader sees it immediately. Use the split as a quiet permission lever when you need to bring an External user into the loop on a project without re-configuring per-project assignments.

Assign a team to a project, offer, or request

Team-based assignment is the main reason teams exist:

Open the project (or offer or request).
Click Project assignment (top of the page).
In the right-side panel, find the Team assignment section.
Pick the team from the dropdown. Search by name if your workspace has many.
(Optional) Add an additional team. Multi-team assignment is supported.
Save.

External team leaders gain visibility on the project. Assign External team members individually if they need access.

Multi-team assignment

A single project can be assigned to multiple teams at once. Use this when work spans groups, for example a commercial project where the Sales team and the Installation crew both need visibility. Each assigned team is independent, and the leaders of each see the project.

Replace vs add when assigning

Team assignment is additive by default: adding a team to a project doesn't remove the previously-assigned team. To re-assign the project from team A to team B, remove team A in the assignment panel, then add team B.

Why "Project assignment" matters for your reporting

Sales-performance dashboards aggregate by Key Account Manager and by team. A project with at least one team assigned appears in that team's report, so keep assignment hygiene tight if you want every active project counted on the team-level dashboard.

Team-level assignment on tasks

Tasks have their own team-assignment field, separate from the project-level assignment.

Open the task.
Click into the Teams field (separate from Assignees).
Pick the team.
Save.

The task carries the team. For task visibility, the same leader / member rule applies: External team leaders see the task; External team members see it when assigned individually.

Note: If every team member needs to be notified about a task, add them individually as user-assignees as well as assigning the team.

Round-robin and other auto-assignment patterns

Lead distribution across team members uses these patterns:

Manual round-robin via the team leader. The team lead receives the lead (because they're a leader on the assigned sales team) and assigns the Key Account in rotation. The leader's morning routine becomes "triage the new leads in my queue and pass each to the next rep on the list."
Key Account assignment at lead intake. If you configure your lead-source integration to assign a specific Key Account at intake, each lead lands directly on the named rep, bypassing team-level triage. This works for "the new lead always goes to whoever was on intake today" patterns.
Custom Sales Assistant filter. The Sales Assistant module has its own filter logic that can scope what each rep sees. Ask your account manager about custom Sales Assistant configurations for finer routing.

Team vs individual user assignment, which to use when

The three project-assignment slots are:

Key Account Manager. Exactly one per project. Main contact for the customer. Receives every offer-related notification. Shown on the offer PDF cover and in the customer portal as the main contact. Always individual, never a team.
Users. Additional individuals who get edit access (within their role limits). Many users can be assigned at once. Use for "the technical back-office should also see this" or "the installation crew lead should be CC'd."
Teams. Group assignment in one click. Use for "everyone in the sales team" or "everyone in the installation crew."

Combine them as needed. A typical project has one Key Account, two individually-assigned project users (the planner, the installation lead), and one assigned team (the installation crew). Visibility unions across all three: anyone covered by any path can see the project.

Use a team when:

The work is for a recurring group of people (sales team, installation crew, planning team).
You want assignment to survive turnover. When a new rep joins the team, they automatically pick up future assignments without per-project re-configuration.
The group has a meaningful leader / member split (sales team with one lead, multiple reps).

Use individual user assignment when:

The work is for one or two specific people, not a recurring group.
You want a specific person to be the "go to" without enumerating them via team membership.
The Key Account role is the right fit (one main contact per project).

Team calendar

When you create a team, Reonic automatically creates a team calendar with a 1:1 link to the team. The calendar shows up in the Calendars module immediately, with no manual setup.

Team leaders can write events on the team calendar (create, edit, delete).
Team members can read events on the team calendar.
Other users see the team calendar when it's been shared with them explicitly via the calendar's settings.

Find the team calendar

Open the Calendars module (left nav).
Find the team calendar in the calendar list. It's named after the team.
Toggle it on to see its events in your calendar view.

Set the team calendar inactive

If your team doesn't need a calendar (for example, it's a virtual grouping for visibility only, with no shared appointments), you can deactivate the calendar so it doesn't appear in everyone's calendar list:

Open Calendar settings > Team calendar.
Set the calendar to inactive.
Save. The calendar still exists but doesn't surface in calendar views.

Customise the team calendar

Optionally assign a colour and a category to the calendar. This helps when your team has many calendars active at once and you want them visually distinguishable. The category drives the calendar's grouping in the calendar overview.

Note: The team calendar is structurally tied to the team and lives and dies with it. To share appointments without a team, create a regular shared calendar (not a team calendar) and share it explicitly with the users you want.

Nested teams, hierarchical teams

Reonic supports nested teams: a parent team containing sub-teams in a tree structure. Use this when your org has a regional manager overseeing several city-level crews, or a head of sales overseeing two regional sales teams.

Create a sub-team

Go to Settings > Users and Teams > Teams.
Click Create team.
In the Parent team field, pick the parent team.
Fill in name / description / members as usual.
Save.

The sub-team is nested under the parent. The sub-team's leaders are leaders of the sub-team only (not automatically of the parent). To grant a user visibility across the whole tree, make them a leader of the parent team. They then inherit visibility down through every descendant team they lead.

How visibility flows in a sub-team tree

Team leaders of a parent team see entities assigned to the parent team and entities assigned to every descendant sub-team they lead (transitively, all the way down the tree).
Team leaders of a sub-team see entities assigned to that specific sub-team and its descendants. Entities on the parent team above them stay with the parent's leaders.
Team members see what they're individually assigned to. They don't inherit team visibility, even when their team has a parent.

This models the "regional manager sees all crews under them" pattern cleanly. The regional manager is a leader of the regional parent team and sees every city crew's projects without per-project assignment.

Move a sub-team under a different parent

Open the sub-team's detail page.
Click Move team (or change the Parent team field).
Pick the new parent, or pick None to make it a top-level team again.
Save.

Moving a team recalculates the leaders' visibility immediately based on the new structure.

Note: A team can't be its own parent, and two teams can't share the same name at the same tree level. Reonic keeps names unique within a parent.

Teams across sub-accounts

If your company runs multiple Reonic workspaces (for example, a parent agency with sub-account child workspaces for each franchise location), teams are per-workspace. The patterns:

Same team name in each workspace. To have a "Sales team" in every sub-account, create it manually in each workspace with consistent naming.
Workspace switcher for cross-workspace users. A user who belongs to multiple workspaces (for example, a parent admin overseeing children) switches between workspaces via the avatar dropdown. Their team membership is per-workspace: in workspace A they might be a leader of the sales team, in workspace B they might not be on any team.
For aggregated cross-workspace management, ask your Reonic account manager about parent-account / agency features. Reonic offers configurations for multi-entity setups that go beyond what self-serve teams cover.

Team reporting

Team-level reporting is available through Reonic's sales-performance dashboards and the Sales Assistant module.

Sales-performance dashboard. Aggregates projects, offers, and revenue by Key Account Manager and (where configured) by team. Find it in the Reports module or via the Sales Assistant.
Per-team project list. Open a team's detail page; the team's currently-assigned projects appear in a list. Click any to jump to it.
Per-team calendar load. The team calendar gives a rough visual of how booked the team is.
Custom roll-ups. For a team-level activity view across all of a team's projects, ask your account manager about custom dashboards or the Sales Assistant.

Note: If your team-level numbers look off, the first thing to check is project assignment. A project counts on a team's report once it has that team assigned, so keep assignment hygiene tight.

Per-team report customisation

You can ask your Reonic account manager for custom report configurations specific to your team structure, for example "weekly close rate by sales team" or "installations completed per crew per month." These typically configure on the Sales Assistant or as a custom dashboard, rather than self-serve filters in the standard reports.

Delete a team

Open Settings > Users and Teams > Teams.
Click the team's row.
Click Delete team (or Archive team, depending on your version).
Confirm.

Deleting a team has consequences:

Project assignments referencing the team are removed. External users who could see those projects only through the deleted team lose visibility. Restore their access by re-assigning the project to another team or to the user individually.
The team calendar is deleted along with the team. Events on the calendar are removed from the calendar surface (see Team calendar above for the 1:1 relationship).
Sub-teams need to be re-parented first. Reonic blocks deletion while a team has non-archived child sub-teams, so move the sub-teams to a different parent (or top-level) before deleting.

Note: Before deleting a team, transfer its active projects to another team. Otherwise External users tied only to the deleted team lose access, and the original Key Account has to reassign each project manually. A good "decommission a team" checklist: re-assign every project, move sub-teams, confirm the calendar isn't in active use, delete.

Why offers vanish after you delete a team

This is the most common gotcha: deleting a team that was the sole visibility path for an External user causes those projects to disappear from the External user's lists. The projects themselves are fine, still there and still assigned to the right Key Account, but the External user no longer has a visibility path. Re-assign the project to a different team (or to the External user individually) to restore access.

Why an installation team can't see photos

If your installation team is missing photos from the technical site visit:

Check the Project assignment on the visited project. Is the team assigned at all?
Check team membership. Are the installers members or leaders? Members alone don't see the project, so promote the relevant installers to leaders, or add them as individual project users.
Check file sharing on the photo files themselves. Where file access control is turned on for your workspace, files can be set to private and need explicit sharing.

Organise installers by specialisation, region, or skill

Free-text team names give you a lot of flexibility. Common patterns:

By specialisation: AC installers, DC installers, Heat-pump crew, Roof crew. Assign projects to the team whose specialisation matches.
By region: Berlin sales team, Munich installation crew, Hamburg planning team. Combine with the Key Account assignment for finer routing.
By customer tier: Enterprise accounts team, Standard accounts team. Route high-touch commercial projects to the Enterprise team.
By project type: Commercial sales, Residential sales. Useful when sales reps specialise in one product line.

Team names are free-text, so adopt the naming convention that helps your day-to-day routing decisions. Be consistent: AC Installers and AC installers are two different teams (matching is case-sensitive).

Per-team kanban and project visibility

The lead pipeline kanban is workspace-wide, filtered by the user's permissions. Patterns to approximate a team-level view:

Filter the kanban by Key Account Manager. If your team uses consistent Key Account assignment (every team member is the KAM on their own projects), filter the lead kanban by the assignee list to see "this team's kanban."
Use the per-team project list. The team detail page surfaces all projects currently assigned to the team. It's a list rather than a kanban, but it gives a quick "what's on this team" answer.
Custom Sales Assistant view. Your account manager can configure custom views in Sales Assistant that scope to a team's projects.
Commercial task kanban (per-project). Every commercial project has its own task kanban, accessible from the project page. Combined with team assignment on the project, the kanban becomes per-team-per-project.

Project assignments, Key Account, users, teams

When you open a project and click Project assignment (top of the page), three assignment types appear:

Key Account Manager. The main contact for the customer. Exactly one Key Account per project. Receives every offer-related notification. Shown on the offer PDF cover (with photo if uploaded) and in the customer portal as the main contact. Assigning a new Key Account replaces the current one; it's not additive.
Users. Additional people who get edit access (within their role's limits). Many users can be assigned at once. Typical: technical back-office, installation lead, installation crew.
Teams. A whole team in one assignment. The leader/member rules above apply.

Why project assignment matters

Visibility for External users. They see projects they're explicitly assigned to (or assigned via team-leader inheritance). Assignment is what opens a project to them.
Reporting. Sales-performance dashboards aggregate by Key Account. A correct Key Account is what counts a deal toward the right user.

Restrict a sales rep to their own leads

This is the External-user setup:

Open the user row and tick External user.
Save.
From now on, the user sees projects where they are the Key Account, a project user, or a leader of an assigned team.
For new leads they should own, assign them as Key Account when the lead lands.

For Editors who aren't External users, Editors see the whole workspace by default. To enforce "their own only," tick External user.

Note: Limiting which dashboards (cards / pipeline views) an Editor can open is a partial workaround for finer segmentation. Ask your account manager if you need dashboard-level scoping via a custom Sales Assistant view.

Hide files from other customers

The customer portal scopes files to the project automatically: customers only ever see files in their own project.

For internal users, to hide certain files from teammates, turn on file access control for your workspace (a Settings option) and set sensitive files to private or share them with specific users only.

Transfer a workspace or change the owner

If the workspace owner leaves the company:

Promote their replacement to Admin first.
Have the new Admin sign in and verify they can manage Users and Settings.
Remove the departing user from the workspace.

Ownership transfer is just ensuring at least one Admin remains; there's no separate "primary owner" field that needs handoff.

For billing-level changes (whose card is on file, where invoices go), open Settings > Company settings > Licenses & Billing and update there. The billing contact is independent of the Admin role.

To hand a seat to a replacement colleague (someone leaves and their replacement takes over), you can't rename the existing user, because email and name aren't editable in-app. Instead, create a new user for the replacement (Add user), reassign the leaver's projects, Key Account ownership, and team memberships to them, then remove the leaver. If preserving the exact same user record matters (so assignments stay attached automatically), contact Reonic support to change the email and name on the existing record.

Things to know

Access is layered. Every action checks that your workspace includes the area, the user has area access, the user's role is high enough, and the relevant individual right is on. Missing one blocks the action.
Roles are per-workspace. A user can be Admin in workspace A and Viewer in workspace B: same email, different roles per workspace, with an independent set of rights in each.
Email is the unique key. A workspace can't have two users with the same email. Because email is fixed in-app, you can't free up an address by renaming the outgoing user: remove that user first (or have Reonic change the old record's email), then add the new one.
Keep at least one Admin. Always promote a replacement Admin before removing or demoting the outgoing one, so the workspace keeps an Admin who can open Settings.
Role changes are silent. Reonic doesn't notify users when their role changes; they see the new powers (or restrictions) on next sign-in. Mention role changes out-of-band.
External users are always Viewer or Editor. The flag pairs with those two roles, not Admin (Admins are full-workspace by design).
Sub-contractors don't always need a license. If they only need to view assignments and complete checklists on the Mobile App, a Viewer + External user + assigned-projects setup may be enough, or a Residential Installer license for installation-only access. Check with your account manager based on which areas they need.
Some individual rights become available once enabled. Certain rights appear in the list once your account manager enables the underlying capability for your workspace. The chain is: capability enabled for your workspace, the right becomes visible, you grant it per user, the user's role is above Viewer, the user can use the capability.
One right defaults on for Editors. Plan permission service (request planning service) starts on for Editors; the rest default off.
Licenses are optional. Some workspaces rely on role plus area access alone.
The Installations tab is an area toggle, not an individual right. Residential and commercial installations toggle separately.
Teams are a permission layer, not a replacement. Role, area access, and individual rights still apply on top of team membership. A user without Edit prices still can't edit prices, even as a team leader on a project assigned to their team.
Team membership is admin-set. Members are added and removed by an Admin; there's no "request to join" workflow.
No notification on team-membership change. Users discover they've been added or removed on next sign-in (or when they look at the team calendar / assigned projects). Tell them out-of-band.
A user can belong to many teams. There's no "primary team" concept.
The team calendar is auto-created and structurally tied. It lives and dies with the team. To hide it without deleting the team, set it inactive.
Reonic teams are set inside Reonic. Team membership isn't provisioned from an external HR / SSO group, so configure it after sign-in even when users authenticate via SSO.

Need help?

Step-by-step questions about user setup, roles, or licenses → contact your Reonic account manager.
Buying more licenses or changing your plan → talk to your account manager.
Lost device / urgent access revocation → remove the user from the workspace on their user row (then re-add if needed) to end their access.
Feature requests (per-field price hiding, dashboard segmentation, bulk user import) → share them with your account manager.

Last updated on August 4, 2026

Users, roles, licenses, and teams

On this page