Last updated: 9/11/2026

Access Model

---

User Management

---

Collection Profile

All users in ShareAspace have a profile at collection level. The collection stores global user information, such as the display name and avatar image, in a Collection Profile. The user's email address identifies the Collection Profile. After successful authentication with an Identity Provider, the user's email address is passed as a claim for authorization.

Space Profile

A user has one space-specific Space Profile for each space that the user belongs to. The Space Profile is stored in the space and stores the user's:

• Space-specific information filter settings
• Modules active on the user's space home screen. Only modules available for that space can be configured.

The space controls user access within the space.

Access Model

---

This section describes the conceptual Access Model constructs of ShareAspace. Refer to the picture below when reading the documentation. The internal model reference documents contain the corresponding AccessRights, Participant, Role, and AppliedRoleReference definitions.

This article describes participant-level access. Access to individual objects can also be affected by ownership, co-ownership, co-readers, and the structure of a Unit of Information. See the Unit of Information access article for those rules.

The access rights use Boolean-style combinations:

• AND means that every applicable restriction must grant a right.
• OR means that any one applicable role assignment can grant a right.

Access is evaluated for a user and a Participant. A role assignment provides the user's access to the Participant, and the Participant's Internal Access limits that access. When access is requested through an External Access relationship, the external access and the receiving Participant's Internal Access limit it further. When a user has multiple role assignments, the resulting access is the OR-combination of the access calculated for each assignment.

Participant

All data within a ShareAspace space is owned by a Participant or by the Space itself. A Participant is a system-specific object that tracks data ownership and helps control access to that data. The Participant is stored in the space and is self-owned. It is created during space bootstrap or at runtime.

Role

A Role is a system-specific object that defines access. A Role has a name and a set of access rights. A Role can combine the following access attributes.

Attribute	Description
Create (C)	Instantiate a new Unit of Information (UoI). The created UoI shall have the owner set to the Participant that the role assignment concerns. Note that create is not required to instantiate entries inside a UoI.
Read (R)	Retrieve/read UoI/Entries that are owned by the Participant where the role is applied.
Update (U)	Create new entries, delete existing entries or alter values of existing attributes inside a UoI owned by the Participant where the role is applied.
Delete (D)	Delete a UoI owned by the participant that the role assignment concerns. Note that delete is not required to delete entries inside a UoI.
FileVault Access (FVA)	Retrieve PLM-vaulted files from a UoI owned by the Participant where the role is applied.
Execute Operation (EXE)	Execute operations held by a UoI owned by the Participant where the role is applied.
Awareness (AWA)	Allow another Participant to discover the Participant granting this access, the Organization referenced by its .forOrganization property, and the users whose Space Profiles are owned by it. Note that AWA is still required even if other Access Rights are added to the External Access.
Grant Detailed Access (GDA)	Grant another Participant ReadShare/FullShare to UoI/VersionEntry/DefinitionEntry owned by the Participant where the role is applied.
Grant User Access (GUA)	Allows a user to manage the SpaceProfile references of all applied role references contained within a Participant, i.e. allows the user to add/remove user access by adding/removing role assignments for that user.
Grant Participant Access (GPA)	Create a new Participant at runtime in the space.
Grant External Access (GEA)	Establish an External Access Rights (EAR) between an unrelated Participant and the Participant where the role is applied.
Manage Space Definitions (MSD)	To manage the definitions of the space. This is a global access attribute, i.e. a user with a role assignment with this modifier can manage definitions of the space regardless of what Participant the role assignment is applied to.
Lock (L)	Allows for "checkout" of objects owned by the Participant where the role is applied.
DelegateLock (DL)	Allows for handing over a "checkout" of an object to another user.
Force Unlock	Allows for removing a lock from an object even when the user does not own the lock.

Roles are stored at space level. This allows different roles in different spaces, including roles with the same name but different access rights.

Applied Role Reference and Role Assignment

An Applied Role Reference defines which roles are available for a Participant. A Space Profile (user) receives access to a Participant through one of these roles. The role assignment is stored at space level.

Sub Participant

A Sub Participant is a Participant owned by another Participant. The Sub Participant grants the owning Participant full external access (AWA, R, U, D, FVA, GUA, EXE). To create a Sub Participant, the user needs Grant Participant Access. All Applied Role References from the owning Participant are copied to the Sub Participant. The creating user's Space Profile References in the owning Participant are also copied to the Sub Participant.

The user that creates the Sub Participant has the same access rights in the new Sub Participant as in the owning Participant because the roles are copied from the Participant to the Sub Participant.

Other users in the owning Participant have the same access in the Sub Participant as in the owning Participant except for C, GDA, GUA, GPA, GEA, and MSD. To gain these rights in the Sub Participant, the user needs a Role in the Sub Participant with the relevant Access Right.

Internal Access

Internal Access for a Participant is set up when the Participant is created and cannot be changed at runtime. By default the Internal Access of a Participant is full access. The Internal Access of a Participant is AND-operated with any role assignments given to a user for that Participant. Internal Access can therefore restrict the rights granted by those role assignments.

Internal Access example

Document 1 is owned by Participant 1. Participant 1 has Read (R) as Internal Access. User 1 has a Role assignment with "edit" access (C, R, U, D) in Participant 1. Because of Internal Access, User 1 receives only Read (R) access to data owned by Participant 1.

User 1 access to Document 1

	C	R	U	D
U1 Role assignment in P1	1	1	1	1
Internal AR P1	0	1	0	0
Result	0	1	0	0

External Access

Access can also be set up between Participants. A granting Participant can give a receiving Participant any combination of R, U, D, FVA, EXE, GUA, and AWA access. External Access never grants Create (C); Create applies only to a role assignment within the Participant where the new UoI will be owned. The access between two Participants is called External Access.

Attribute	Description
Read (R)	Retrieve/read UoI/Entries that are owned by the granting Participant.
Update (U)	Create new entries, delete existing entries or alter values of existing attributes inside a UoI owned by the granting Participant.
Delete (D)	Delete a UoI owned by the granting Participant. Note that Delete is not required to delete entries inside a UoI.
FileVault Access (FVA)	Retrieve PLM-vaulted files from a UoI owned by the granting Participant.
Execute Operation (EXE)	Execute operations held by a UoI owned by the granting Participant.
Awareness (AWA)	Allow the receiving Participant to discover the granting Participant, the Organization referenced by its .forOrganization property, and the users whose Space Profiles are owned by it. Note that AWA is still required even if other Access Rights are added to the External Access.
Grant User Access (GUA)	Allows users in the receiving Participant to manage the SpaceProfile references of all applied role references contained within the granting Participant. This allows users to add or remove access through role assignments, including inviting a new user.

When a Participant is given External Access to another Participant, users with a role assignment in the first Participant receive the intersection of their role assignment access, the first Participant's Internal Access, the External Access relationship, and the second Participant's Internal Access. Create is not propagated through External Access.

The Internal Access of a Participant is also AND-operated with any External Access given to other Participants. It can therefore restrict the External Access given to other Participants.

Awareness example

Participant 1 grants Awareness (AWA), but not Read (R), to Participant 2. Users with access through Participant 2 can discover Participant 1, the Organization referenced by Participant 1's .forOrganization property, and users whose Space Profiles are owned by Participant 1. They cannot read UoIs owned by Participant 1 because Read access was not granted.

External Access example

Document 1 is owned by Participant 2. User 1 has a Role assignment with "edit" access (C, R, U, D) in Participant 1. Participant 1 is then given Read access (R) to Participant 2. User 1 has C, R, U, D access to Participant 1 because of the role assignment. User 1 has Read (R) access to Participant 2 because the intersection of (C, R, U, D) and (R) is (R). Create is not available through the External Access relationship.

User 1 access to Document 1

	C	R	U	D
U1 Role assignment in P1	1	1	1	1
Internal AR P1	1	1	1	1
External AR P1 in P2	0	1	0	0
Internal AR P2	1	1	1	1
Result	0	1	0	0

Note

External Access does not propagate between Participants. External Access given to one Participant applies only to users with an applied role in that receiving Participant.

User 1 access to Document 1

	C	R	U	D
U1 Role assignment in P1	1	1	1	1
Internal AR P1	1	1	1	1
External AR P1 in P2	0	1	0	0
Internal AR P2	1	1	1	1
External AR P1 in P3	0	0	0	0
Result	0	0	0	0

If User 1 also has a role assignment for an Applied Role called "Creator" in Participant 3, that access is OR-combined with the access calculated above.

	C	R	U	D
U1 Role assignment in P1	1	1	1	1
Internal AR P1	1	1	1	1
External AR P1 in P2	0	1	0	0
Internal AR P2	1	1	1	1
External AR P1 in P3	0	0	0	0
--- OR ---
U1 Role assignment in P3	1	1	1	1
Internal AR P3	1	1	1	1
Result	1	1	1	1

Special case Participant

The Space Participant is a special type of Participant with additional business logic.

The Space Participant owns reference data such as units and properties that should be accessible to everyone in the Space. Because it is the default owner of shared information, every Participant created at runtime is automatically granted access to the Space Participant. The granted external access is (R) Read, (FVA) File vault access, and (AWA) Awareness.

Role-based SoftType operations

The ShareAspace access engine supports additional access control for SoftType operations, such as creating, updating, and reading SoftType instances.

Basics

AllowedRoles can restrict operations on a SoftType, including the any SoftType. It can also restrict update and delete API routes at SoftType definition level. A DataExchange job can use it to define which role@participant can schedule the job.

AccessRights calculation for links in API

• If SoftTypeDefinition has no AllowedRoles section, return the current role@participant rights.
• If the complete role@participant matches, return the allowed rights.
• If both role and Participant match separately, return the bitwise AND of their allowed rights.
• If only the role matches, return the role's allowed rights.
• If only the Participant matches, return the Participant's allowed rights.
• If nothing matches, return the current role@participant rights.

AccessRights check for commit validation

• Retrieve the current user's access for the specific UoI.
• If there is no AllowedRoles section, return the user's access.
• Check AllowedRoles for all the user's roles and combine the matching entries.
• If no restriction is found, return the user's access.
• If a restriction is found, return the intersection of the user's access and the allowed rights.