There are normally no rejects when dispatching work carried out in a private workspace. Most conflicts are managed automatically.

Rare cases of rejects are listed in the rejects file.

If you have access to the writing access management function, you can, for example, protect an object in the repository while a user is deleting it in his/her private workspace. When the user dispatches his/her work, he/she is no longer allowed to delete the object and the deletion is rejected.

A user renames an object in his/her private workspace, for example, from "Customer" to "Customers". Then another user dispatches his/her private workspace in which he/she created an object having the same name "Customers".

When the first user dispatches his/her private workspace, since the "Customers" object already exists, the object "Customer" cannot be renamed "Customers". The rename command will therefore be rejected.

A user creates a link for which there is a uniqueness check. For example, he/she indicates that the "Order" message is sent by the "Customer" org-unit. In the meantime, another user indicates in his/her private workspace that the "Order" message is sent by the "Customers" org-unit. When the second user dispatches his/her private workspace, the link is rejected if the uniqueness control imposes that a message can be sent by only one object.

Other attributes besides name may also be checked for uniqueness. If two users give two different objects the same value for this attribute, the second update will be rejected.

If a user has made changes to an object in his/her private workspace and the object has been deleted by another user, the updates are rejected. The Connect and Change commands concerning this object are also rejected. All these rejects are listed in the private workspace report file.