Request Access Is Best Practice

The recommended operating model is that the Customer enters from the outside through Emiko App, identifies the correct Partner, and requests access to the relevant Emiko Site or scope.

• The Partner can then approve or reject the request.
• This keeps identity, responsibility, and access flow aligned.
• Manual invitation from the Partner side can still be used in special cases, but it is not the preferred primary flow.

Partner Controls Access

The Partner decides who gets access and what that access includes.

• Access can be granted to a company identity or to an individual user, depending on the Emiko Organization, Emiko Site, and use case.
• Access can be broad by default in one Emiko Site and more specific in another.
• The same platform supports both simple approval patterns and more restricted approval patterns.

Permissions Can Be Limited

Approval does not have to mean unrestricted access. The Partner can limit the scope that becomes available after approval.

• Access can be limited to selected equipment or selected services.
• Access can be limited to a defined time period.
• Access can be restricted by allowed operating method or channel.
• Access can be revoked again when the work or relationship ends.

Role-Based And Group-Based Control

Emiko uses both role-based rights and group/access-based control.

• Some rights are tied to platform responsibilities such as Vikingegaarden governance, Reseller permissions, Partner operational responsibility, or Customer use.
• Other rights depend on which Emiko Site, group, or granted scope the user belongs to.
• This makes it possible to keep the platform flexible across different industries and operating patterns.

One Partner may choose a simple access model, while another may use more detailed rules for scope, time, and allowed control methods. The access model should follow the operational and commercial reality of that Emiko Site.

What Comes Next