In most cases a simulation object inherits behaviors, such as the ownership, from its parent. For example, if you own a simulation activity, you will also own any documents that you, or other people, create under that activity. Similarly, if you create a copy of a simulation process that you own, you will also own the copy.
Understanding how the following behaviors propagate in new or revised simulation objects will help you understand the impact of Collaboration and Approvals operations:
- Revise
When you revise a simulation object, Process Composer applies the following propagation rules:
- When you revise an object, you become the owner of the new revision. However, if the object is contained by another object, such as a simulation activity within a simulation process, the ownership does not change.
- When you revise a simulation process, Process Composer copies its simulation activities into the new copy. The copied activities retain the revision of the originals.
- When you revise a simulation process or a simulation activity, Process Composer creates copies of any existing data categories and folders.
- When you revise a simulation process or a simulation activity, Process Composer
creates a copy of any owned documents; the copied documents retain the revision of the original.
- When you revise a simulation object, Process Composer duplicates any references so that the new revision contains the
same references as the original.
- When you create a revision of a standalone object, such as a simulation process or an experience, Process Composer does not propagate the access rights of the original object to the new revision. However, when you revise an object contained by another object, Process Composer propagates the access rights (which were inherited from the parent) to the new revision.
- Access
When you change the access rights on a simulation object, Process Composer propagates the access through the children of the object that you own. Therefore, Process Composer gives the same access permission to the simulation object and all of
its owned data.
This functionality does not apply to referenced items. Access to a referenced item is always controlled by the
item itself. For example, a simulation cannot grant access to an item it references, such as a data file.
- Lock/unlock
The lock/unlock behavior is the same as the ownership behavior. When you lock a simulation object, Process Composer propagates the lock down through the children of the object, as long as you have permission to lock the object.
- Copy
The copy behavior is similar to the revise behavior.
- When you copy a simulation process, Process Composer copies its simulation activities into the new copy. The copied activities retain the revision of the originals.
- When you copy a simulation process or a simulation activity, Process Composer creates copies of any existing data categories and folders.
- When you copy a simulation process or a simulation activity, Process Composer
creates a copy of any owned documents; the copied documents retain the revision of the original.
- When you copy a simulation object, Process Composer duplicates any references so that the new revision contains the
same references as the original.
- When you copy a simulation object, Process Composer does not copy the access rights from the original object to the new object.
- The user that performs the copy owns the new object, regardless of who owned the original object.
In addition, Process Composer creates an entry in the history of the new object to indicate that it was created as a copy
and to identify the original object.
- Create Object
When you create a simulation object, Process Composer sets the owner of the new object to be the same as the owner of its parent. Therefore, the parent object and its children will have the same owner. This behavior does not affect the originator attribute of the object. The originator is always the name of the person who created the object.
- Change Owner
When you change the owner of a simulation object, Process Composer propagates the ownership through all of the children of the object. However, the propagation continues only as long as you have permission to change ownership of the child object.
If a document is referenced by a simulation object, you must have read access to the document for the change owner procedure to succeed.
- Promote/demote
Process Composer does not perform any propagation when you promote or demote a simulation object. In addition, promotion or demotion does not depend on the state of the children. For example, you can promote a simulation process even though its simulation activities are not ready to be promoted.