Assigning roles in a new domain

Purpose

Many roles in ArQiver are domain-level roles. That means they become meaningful only after the correct domain exists and the right ownership has been assigned inside that domain.

This page explains the minimum path needed to make those roles usable.

Quick start

If you want to assign someone a domain-level role such as Operator, Privacy Officer, Archive Officer, Maintenance Officer, Product Owner, Product Manager, or Member, you typically need to follow this order:

1. Make sure the dataspace exists.
2. Sign in as a role that can create a domain, typically a Dataspace Owner.
3. Create the domain.
4. Assign a Domain Owner to that specific domain.
5. Sign in as that Domain Owner.
6. From that domain context, assign the other domain-level roles to the right users.

Only after those steps are in place can those users start acting meaningfully inside that domain.

Why this order exists

ArQiver is designed so that permissions are used in the correct context.

For example:

• an Operator is not just “an operator somewhere”;
• a Privacy Officer is not just “a privacy officer in general”;
• a Product Owner is not just “a person with product permissions”.

These roles belong to a domain context. Without that domain, and without the right ownership inside it, those responsibilities do not yet have the structure they need.

Practical flow

Step 1: Create the domain

The first requirement is that the domain itself exists.

This is typically done by a Dataspace Owner, because domain creation belongs to the structural governance layer of the dataspace.

Step 2: Assign a Domain Owner

Once the domain exists, a Domain Owner must be assigned to that specific domain.

This is the role that governs meaning, structure, and responsibility within the domain.

Step 3: Switch into the domain context

After that, sign in or switch to the Domain Owner role for that domain.

This is important because ArQiver uses an active role model. The user must act from the right role and context before the correct management options become available.

Step 4: Assign the remaining roles

From the domain owner context, you can then assign other domain-level roles such as:

• Operator
• Member
• Archive Officer
• Privacy Officer
• Maintenance Officer
• Product Owner
• Product Manager

At that point, those roles are no longer abstract. They now exist inside a real domain where users can actually work with them.

A simple mental model

You can think about this as a dependency chain:

Dataspace -> Domain -> Domain Owner -> Other domain roles

Each step prepares the next one and helps ensure that roles become usable in the right place.

Related pages

• Understanding the ArQiver hierarchy
• Roles and responsibilities
• User and domain management