About Access

You select Sharing from the navigation pane to do the following for the object in the table page:

Add people that can access the object.
Add credentials that can access the object. Users with matching credentials (role, collaborative space, and organization) can access the object.
Modify the access level.

See Sharing Page for more information.

By default, the owner of an object has access to a Process Composer object, regardless of the lifecycle state. However, the lifecycle state may prevent the owner from modifying the object; for example, a simulation process in the Complete state cannot be modified. Conversely, in general, no other user has access to the object unless specifically granted access by the owner (or by an Access Manager).

Process Composer defines the following access levels:

Basic: You can view the simulation object, but you cannot download any files associated with it.
Read: You can view the simulation object, but you cannot modify it.
Read Write: You can view the simulation object and modify it.
Add: You have read/write access, and you can add content to the object, such as a new document or folder. You must have Add access rights to run a simulation process or a simulation activity.
Remove: You have read/write access, and you can remove content from the object. Remove applies only to removing an object from its container. If you own the object being removed and no other objects refer to it, Process Composer deletes it from the database. However, if another object refers to the object being removed, the reference is maintained and the object is not deleted from the database.
Add Remove: You have read/write access, and you can both add and remove content from the object.

Process Composer grants access rights to every simulation object. The access rights that are granted to you are determined from a combination of factors:

Whether you are the owner of the object.
Whether the owner has granted you access.
The role to which you are assigned.
The policy governing the object and its lifecycle state.

For example, when you create a simulation process, you are the owner and you have full access to the simulation process and everything it contains. However, when you promote the simulation process to the Complete or Review state, no person, including the owner, can modify the simulation process or add content to it.

A spreadsheet that describes the operations you can perform on a simulation object given its lifecycle state and your access level is available from "What PLM operations can be performed based on lifecycle and access level" in the Dassault Systemes Knowledge Base at http://support.3ds.com/knowledge-base/.

Simulation objects inherit access from their parent objects. For example, if you have read access to a simulation process, you will also have read access to any files, folder, or subfolders inside the simulation process. Similarly, you can access a job only if you have access to the simulation process or simulation activity that is attached to the job.

This inheritance behavior does not apply to referenced items. Access to a referenced item is always controlled by the item itself. For example, a simulation process cannot grant access to an item it references outside the simulation process, such as a data file.

Access levels build upon one another. When you have one access level, you have all the permissions allowed in the lower levels. For example, if you have add access, you also have read/write access.

In addition, a user can lock an object, which affects the access rights of other users. If an object is locked by another user, you cannot modify the object until that user unlocks the object.

When you revise a simulation process, simulation activity, experience, or document, you can choose whether Process Composer will copy the access rights to the new copy or reset the access rights.