Permissions

Folder creation rights are deliberately split. Only a Platform Admin An access permmissions role. The administrator role in Nintex Processes who can create root folders, manage workspace and folder access, create and edit drafts, publish where permitted, archive, restore and permanently delete processes. can create a root level folder, which keeps the top level of the workspace under workspace-level control. Below that, only a folder Owner An access permission role. The folder Owner role in Nintex Processes can manage folder settings, access, permission sets, inheritance and sub-folders; create, edit, publish and archive within owned folders, and assign Process Owner or Process Expert roles to a process. can create sub-folders inside a folder they own. Designer An access permissions role. A Designer in Nintex Processes can create processes outside a folder, design and edit drafts, publish where permitted, and assign Process Owner or Process Expert roles to a process. and Contributor An access permisions role. A Contributor in Nintex Processes can view, create, edit and publish processes and filed drafts in assigned folders, assign Process Owner or Process Expert roles to a process, and archive in assigned scope. roles can only create processes, never folders.

The order in which you create folders is important because each level inherits the access permissions granted by its parent folder.

1. A Platform Admin An access permmissions role. The administrator role in Nintex Processes who can create root folders, manage workspace and folder access, create and edit drafts, publish where permitted, archive, restore and permanently delete processes. creates the root folder. This is the only step nobody else can do.

2. Assign at least one folder Owner immediately. Managing everything below this point is the responsibility of the folder owner, and the folder prevents you from removing the last owner later..

3. The folder Owner grants access at the top level. Decide who is a Viewer An access permisions role. The user can view published processes., Contributor An access permisions role. A Contributor in Nintex Processes can view, create, edit and publish processes and filed drafts in assigned folders, assign Process Owner or Process Expert roles to a process, and archive in assigned scope. and Designer An access permissions role. A Designer in Nintex Processes can create processes outside a folder, design and edit drafts, publish where permitted, and assign Process Owner or Process Expert roles to a process.. Granting access permissions here is what makes those people eligible for process roles further down in the sub-folders.

4. Create sub-folders. They inherit the parent folder’s access permissions list by default. Leave them inherited unless there is a reason not to.

5. Break inheritance only when the audience genuinely differs. Keep in mind that permission changes cascade to all child items, and disabling inheritance creates a standalone access permissions list that must be managed manually.

6. Finally, assign your process specific roles: Process Owners A process role. A Process Owner in Nintex Processes is responsible for managing the lifecycle of the process. and Process Experts A process role. A Process Expert in Nintex Processes is responsible for keeping the process definition updated to match how the organization actually functions.. Only users who already hold visibility and edit permissions on the process can be selected, so you must grant folder access first.

When you create a folder, the Inherit access from parent folder toggle is on by default. Breaking inheritance by turning that toggle off detaches this sub-folder from the access permissions of the parent. The folder then keeps its own access permissions list, and that new list becomes what its own descendants inherit. Anyone who is not on the new permissions list can no longer view the folder and everything inside it, even if they can still view the parent folder.

Restoring inheritance sets the folder access permissions back to the parent folder’s permissions list.

Note: Break inheritance only when the audience genuinely differs. Keep in mind that permission changes cascade to all child items, and disabling inheritance creates a standalone access permissions list that must be managed manually.

A process has different access permissions at each state. An unfiled draft process (one that is not in a folder) has no folder permissions and is only visible to the process creator and to the participants. Once a draft is filed, the folder permissions are applied.

Note: A published version of the process can only ever be viewed, never edited. Users with edit permissions can modify the process, but their changes are saved as a new draft version until they are published.

Process Viewers can never see draft versions of a process. This restriction goes beyond simply hiding actions. Viewers do not see draft cards, draft rows, draft badges, draft search results, or any controls for creating, editing, publishing, archiving, or managing permissions. For example, if a folder contains one published process and three draft processes, a Viewer sees only the published process.

Permission status indicates the progress of Nintex Processes as it applies or updates access permissions for a folder, draft, or process after the item is created, moved, modified, or deleted.

Permissions decide who can see or change an item. When you create, move, or change a folder, draft, or process, Nintex Processes accepts your request and applies the permissions in the background. The control you used shows a busy indicator while the permissions are being applied. You then see a confirmation, or a message with a Retry option if the permissions could not be applied.

Nintex Processes does not show a separate permission status label or column. The status appears only as the busy indicator, the confirmation, or the error message on the action you just performed.

What happens to your item

• While permissions are being applied: the button you clicked shows a busy indicator. Keep the dialog or panel open until the indicator stops.

• When permissions are ready: a confirmation message appears, and the dialog or panel closes or the next page opens.

• If permissions cannot be applied: An error message appears, and the button changes to Retry. Nintex Processes does not create or update items that users cannot access. If the operation involves creating a new folder, creating a new draft, or publishing a process for the first time, the item is removed. If the operation involves updating an existing item, the change is not applied, and the item retains its previous permissions or location.

• If you delete an item: the item is removed. Nintex Processes then clears its permissions in the background and does not show you progress or the outcome.

• If you delete an item: The item is removed immediately. Nintex Processes then removes its associated permissions in the background. This cleanup process occurs automatically, and no progress or status information is displayed.

If no response is received within approximately 35 seconds, the action is considered to have failed, and the same error message is displayed.

If an action keeps failing, wait a few minutes and try again. If it still fails, contact your Nintex administrator or support. Include the action you took, the name of the folder, draft, or process, the time, and the exact message that appeared.

1. In the left navigation, under Connection, click Systems.

2. Review the System, Description, and Associated Processes columns. Use the Search box to find a system by name.

3. Click the number of processes in the Associated Processes column to see which processes use the system. If you do not have access to a process, it appears as Restricted access.

Note: When you assign a system to an activity in a process, the list shows the full catalog of systems regardless of your role.

Only Admins see the Create button.

1. On the Systems page, click Create. If no systems exist yet, click Create system instead.

2. In the Create system dialog, specify a Name of up to 150 characters. The name is required and must be different from the name of every other system.

3. Optional: Specify a Description of up to 1,000 characters.

4. Click Add.

1. On the Systems page, find the system and click its System actions menu.

2. Select Edit. If the menu has no Edit option, you cannot edit that system.

3. In the Edit system dialog, change the Name or Description.

4. Click Save.

Deleting a system cannot be undone.

1. On the Systems page, find the system and click its System actions menu.

2. Select Delete. If the menu has no Delete option, you cannot delete that system.

3. In the Delete dialog, read the message, and then click Delete.

Note: The Nintex CE Platform system is reserved and cannot be deleted, even if you are allowed to delete other systems.