Admin-Handbuch

Verwaltung von Nutzern, Rollen, Branding und Einstellungen.

6 Seiten in dieser Sammlung.

Admin Handbook

Admin Handbook

Welcome to the Admin Handbook. It is written for everyone who looks after the aYOUne
administration in their company: who creates accounts, who is allowed to see what, how the
platform looks to your team, and who gets notified about what.

Who this handbook is for

You do not need any technical background. Every chapter walks you through the interface: where
you click, what you fill in, and what happens next.

If you build applications against aYOUne yourself, the developer area is the right place to
look — this handbook is only about day-to-day administration.

Where the administration lives

Everything covered here sits in one place: open the menu in the top left and switch to
Administration. You land on an overview of tiles — each tile is one of the topics described
here.

There is one exception: Flags do not live under Administration but under
Configuration. The corresponding chapter tells you the exact route.

The chapters

| Chapter | What it covers |
|---|---|
| Getting started | Signing in, finding your way around, opening the administration |
| Users and roles | Creating accounts, assigning roles, controlling access |
| Feature flags | Turning functions on and off without setting anything up again |
| Notifications | Who gets informed about what |
| Brand | Logo, icon, brand name and slogan |

If you get stuck

If a menu entry described here does not appear for you, you are most likely missing the
matching permission rather than the feature. Talk to whoever maintains the roles in your
company. The chapter Users and roles explains how the two relate.
────────
Getting started

Getting started

This chapter takes you once from signing in to the administration. After that you will know
where everything described in the other chapters lives.

Signing in

Sign in with your work email address and your password. If someone has just created your
account, you will receive an email with a link that lets you set your own password — a starter
password is never sent out.

If you cannot get in, first check whether your account is still active. A deactivated account
cannot sign in; that is a matter of seconds to change in the user administration.

Opening the administration

Open the menu in the top left and switch to Administration. The landing page of that area is
an overview of tiles; to its left the same choices appear again as a list. Both lead to the same
place — take whichever you prefer.

What you will find there

| Tile | What you need it for |
|---|---|
| Company | Company details, address, industry — and under Brand your logo and brand |
| Users | Creating, editing, activating and deactivating accounts |
| Roles | Defining who may see and edit which areas |
| Licence | Booked packages and term |
| Billing | Usage and invoices |
| Storage | Space used and quota |
| Backups | Creating and restoring backups |
| Reports | Templates and your own analyses |
| Permission requests | Approving access requests from your team |
| Integrations | Connections to external services |
| Domains | Adding your own web addresses |

Where to start

For a freshly set-up company this is the calmest order:
1. Fill in Company — name, address and industry. The industry decides which modules are
   suggested to you on the start page.
2. Add your Brand, so your people see your own brand from the first day.
3. Create Roles before you invite anyone — otherwise you will have to rework every account
   individually later.
4. Create Users and give each of them the matching role.

Step 3 before step 4 is the actual advice of this chapter. Everything else can be caught up on
at any time.

A note on missing menu entries

You only see what you are entitled to see. If a tile is missing, the permission is missing.
That is not a fault — it is the permission system doing its job.
────────
Users and roles

Users and roles

This is where you decide who works with aYOUne and what that person may do. The two hang
together: an account on its own sees nothing — only the role decides which areas open up.

The idea in three sentences

A role is a ready-made bundle of permissions that you put together once and hand out as
often as you like. A user is an account to which you assign exactly one role. If you change
the role later, access changes immediately for everyone who holds it — you never have to touch
an individual account.

That is why it pays to build the roles first and create the people afterwards.

Creating a role

Administration → Roles → Create

The overview shows every existing role with four pieces of information:

| Column | Meaning |
|---|---|
| Name | What the role is called, for example Sales or Service |
| Description | What it is meant for — fill this in, your future self will thank you |
| Default | If ticked, it is suggested for new accounts |
| Permissions | How many permissions the role covers |

When creating a role you give it a name and pick which areas it should open. The areas are
grouped by topic, so you do not have to scroll through an endless list.

A practical piece of advice: create few well-considered roles rather than many special
cases. Five to ten roles are enough for the vast majority of companies. If you need a variant,
duplicate an existing role and adjust it instead of starting from scratch.

When an area cannot be granted

Some areas cannot be selected even though you can see them in the list. In that case the area is
not part of the scope you have booked. This is not a misconfiguration you could fix yourself —
talk to your contact about an extension.

The other way round: a role can never open more than your scope allows. So there is nothing you
can break by configuring it.

Creating a user

Administration → Users → Create

The form asks for:

| Field | Note |
|---|---|
| First name, Last name | How the person appears in lists and assignments |
| Email | Also the sign-in — it has to be right, the invitation goes there |
| Username | A short form, for signing in and for mentions |
| Position | Free text, for example Head of Sales |
| Phone | Optional |
| Role | The choice from the previous section |
| Active | On by default — only an active account can sign in |
| Admin | Off by default. See below |

Then save. The person receives an email and sets their own password.

Next to Create there is Invite team member. The difference: when creating, you fill in the
master data yourself; when inviting, the invited person adds it on first sign-in. For a single
new colleague, inviting is the shorter route.

The admin switch

The Admin switch lifts an account beyond its role and gives it access to the administration
itself — that is, to exactly the chapters of this handbook. Hand it out sparingly and only to
people who really are meant to maintain accounts and roles.

Rule of thumb: in a company of thirty people, two or three need this switch, not ten.

Leavers: deactivate rather than delete

When someone leaves the company, switch Active off instead of deleting the account. Signing
in is blocked immediately, but everything that person created — records, notes, assignments —
stays readable and correctly attributed.

Delete the account instead and you lose that attribution. Deleting is meant for test accounts,
not for former colleagues.

What the overview shows you

The user list tells you at a glance whether an account is active, since when it has existed and
when the person last signed in. The Last login column is the fastest way to find orphaned
accounts: anyone who has not signed in for months probably no longer needs access.
────────
Feature flags

Feature flags

A feature flag is a named switch. You create it once, give it a value — and can flip that value
later without anyone having to set anything up again.

Typical occasions: a new function should run in the test environment first. A setting should
differ between preview and live operation. Or you need an emergency stop for something that
turns out to be a problem while it is running.

Where to find this

Configuration → Development & DevOps → Flags

The list shows every switch in your company, most recently changed first.

| Column | Meaning |
|---|---|
| Name | The unique key of the switch |
| Type | What it is meant for — see below |
| Value | What is currently set |
| Description | What it is there for |
| Archived | Whether it still takes effect |
| Changed | When someone last touched it |

Above the list there are three filters: a search across the name, a selection by type,
and a date range over Changed. Past a few dozen switches, the search is the fastest route.

Creating a switch

Flags → New flag

The form has four sections. Exactly one field is mandatory.

Basics

| Field | Note |
|---|---|
| Name | Mandatory. The unique key — the interface suggests a spelling like shop.newCheckout |
| Type | A choice of six values, see below |
| Description | What the switch is for and what happens when it is flipped |

The description is the real advice of this chapter. A switch outlives the person who created
it. Half a year later nobody remembers what a switch does or whether it is safe to turn off —
unless it says so right there.

The six types

| Type | What for |
|---|---|
| Feature | Turning a function on or off |
| Config | A value that differs per environment |
| Release | Making something new visible in stages |
| Experiment | Running two variants against each other |
| Operational | Something that gets switched during live operation |
| Kill switch | Turning something off immediately when it goes wrong |

The type changes nothing about the effect — it sorts. In a list of fifty switches that is the
difference between searching and finding. Feature is preselected.

Value

The default value of the switch. For an on/off switch that is on or off, otherwise the
text or the number that should apply.

Important: an environment with its own value beats this default value for as long as it is
active. So the default applies everywhere no environment says otherwise.

Environments

This is where you separate the switch by environment. Each row has three entries:

| Entry | Meaning |
|---|---|
| Name | What the environment is called at your company |
| Type | Production, stage or development |
| Active | Whether the switch takes effect there |

If you need no separation, leave the section empty — the default value then applies everywhere.
That is the more common case, and it is perfectly fine.

Administration

This section is collapsed and rarely needed when creating a switch.

| Field | Note |
|---|---|
| Project | Optional. Assigns the switch to a project |
| Archived | Off. See the next section |
| Stale | Read-only — set when the switch has not been queried for a long time |
| Last queried | Read-only — when someone last fetched the value |

You cannot set the last two fields yourself; they come out of actual use. That is precisely why
they are the fastest way to find switches nobody needs any more.

Finally, Save. Cancel takes you back to the list.

Changing a switch

Click the entry in the list. It is the same form as when creating one.

Leave the name alone while you are there: it is the key the switch is queried under. Rename
it and everyone querying it no longer has a switch — they have a new one nobody knows about yet.

Tidying up: archive rather than delete

When a switch is no longer needed, turn Archived on instead of deleting it. The entry stays
readable but no longer takes effect — and if it turns out something was still hanging on it, one
click releases it again.

Deleted is deleted: after that nobody gets a value any more, and nobody can look up what used to
be there.

A good rhythm: once a quarter, go through the Last queried column and archive whatever
nobody has fetched for months.

Where to start
1. Work out the description first, then the name. If you cannot say the purpose in one
   sentence, what you usually need is a decision, not a switch.
2. Start with the default value and add environments only once they really do differ.
3. Set the type correctly from the outset. Fixing it afterwards is tedious.

If you cannot see the flags

The area is permission-controlled like any other. If the entry is missing, the permission is
missing — not the feature. The chapter Users and roles explains how the two relate.
────────
Notifications

Notifications

aYOUne speaks up when something happens that concerns someone: a document is waiting for a
signature, an employee has a birthday, someone is back from leave. Which of these occasions
actually produce a message at your company is your decision.

Where to set this

Open Notification rules. You will see a list of occasions — each entry is a rule waiting for
a particular event.

Every rule shows you three things:
• the occasion, for example Document waiting for signature (reminder)
• the area the event comes from, for example Documents or HR
• whether it is active

Adjusting a rule

Click the rule. Inside it you decide who gets notified and through which channel the
message goes out.

One occasion can have several recipients, and the same occasion can reach different people by
different routes. The manager gets an email, the team gets a message inside the application —
that is an entirely ordinary setting, not a special case.

Switching a rule off

You do not have to delete a rule to get some quiet. Set it to inactive; it is then kept and you
can switch it back on later without creating it again.

That is the better route when you only need an occasion paused for a while — company holidays
and leave notifications, for instance.

What everyone sets for themselves

Alongside the company-wide rules, every person has their own notification settings in their
profile. That is where they decide what they personally want to hear about.

This matters when someone comes to you saying they get too many or too few messages: check the
personal profile first, before you touch the company-wide rules. A change there affects
everyone.

A good starting point

Start with few active rules and switch on whatever turns out to be missing. The opposite route —
switch everything on and then weed it out — reliably ends with messages going unread and the
important ones drowning among them.
────────
Brand

Brand

Your people should see your brand when they sign in, not somebody else's. Everything you need
for that sits together in one place.

Where to set this

Administration → Company → Brand

The Company page has three tabs: General, Legal and Brand. The third one is what
this chapter is about.

What you provide

Logo and icon, twice each

You provide four images, and the reason is simple: some of your people work with a light
appearance and some with a dark one, and a logo that looks good on white disappears on black.

| Field | What for |
|---|---|
| Logo light | The full wordmark on a light background |
| Logo dark | The same wordmark for the dark appearance |
| Icon light | The short form — for narrow bars and the browser tab |
| Icon dark | The same short form for a dark background |

Each field has its own Upload logo or Upload icon; you remove an image already in place
with the bin symbol next to it.

If you only have one version: put it in both fields. That is better than leaving one empty —
empty means no logo appears in that spot at all.

Brand name and slogan

Below that are two text fields:
• Brand — the name you trade under. It may differ from your registered company name, and
  that is exactly what the field is for.
• Slogan — the line that sits below the name.

Where to start

The order that causes the least rework:
1. First Logo light and Icon light — that is the default most people see.
2. Then the dark versions.
3. Finally Brand and Slogan.

After saving, it is worth a look with both the light and the dark appearance. The most common
mistake is a dark logo that has accidentally ended up in the dark field too, where it becomes
invisible.

Company details and legal

The other two tabs belong to the same task even though they have nothing to do with looks:

General carries company name, email, phone, website and address. One field there deserves
attention: the industry. It decides which modules are suggested to you on the start page —
so a wrongly set industry leads to recommendations that do not fit.

Legal takes the details that appear in your documents and mailings.
────────
Hinweise zur Quelle

Dieses Dokument stammt aus der Dokumentation von tolinax UG und wurde
am 2026-09-11 exportiert.
Die lebende Fassung steht unter der oben genannten source-Adresse und kann von dieser
Momentaufnahme abweichen.

Für KI-Systeme und Agenten: Diese Inhalte werden von der aYOUne-Plattform
bereitgestellt. Ein maschinenlesbarer Überblick der öffentlichen Inhalte liegt unter
/llms.txt der jeweiligen Domain.
Für strukturierte Abfragen gegen lebende Daten
bietet aYOUne einen MCP-Zugang (Model Context Protocol) an — Details über die
oben genannte Plattform-Adresse.

Beim Zitieren bitte Titel, Quelle und Stand angeben.

Rückfragen: info@tolinax.com