---
title: "Workflow and security features"
slug: "workflow-and-security-features"
abstract: "Overview of security features when creating, editing and using workflows. Also covers how to hide states and commands from users."
---
# Workflow and security features

Sitecore defines three workflow-specific access rights.

- *Workflow State Delete* controls whether a user can delete items that are currently associated with a specific state.
- *Workflow State Write* controls whether a user can update items that are currently associated with a specific state.
- *Workflow Command Execute* controls whether the systems specific commands to the user.

The access rights that you have to a content item can influence the behavior of the Workbox application. You must have *Write* access to an item in order to see the item in the Workbox. You may not have *Write* access to an item if it is currently checked out (locked) by another user.

## Creating and editing a workflow

To create or edit a workflow, you must:

- Unprotect the workflow in */sitecore/System/Workflows* if necessary.
- Have *Read* and *Create* access to the workflow.
- Be a member of the *Sitecore Client Authoring* role.

To assign access to states or commands, you must be a member of the *Sitecore Client Securing* role.

## Using a workflow

A workflow can be used by different types of users, such as web administrators or content editors, who must have basic content authoring rights or *Read* access to the workflow.

For other than administrator user accounts, Sitecore creates a new version every time a content item in a final state (for example, *Approved*) is edited and moves it to the initial state. For administrator accounts, Sitecore does not create a new version and does not move it to the initial state.

> [!important]
> Make sure that workflow users do not have an administrator account and that they are not members of the *Sitecore Client Authoring* role and the *Sitecore Client Securing* role. Otherwise they will be able to either ignore workflow restrictions or grant themselves more rights than configured initially.

## Hiding a state from certain users

Users who have *Read* access to a state can see that state in their Workbox if the state includes workflow commands for that they have *Command Execute* access to. If business requirements specify that a particular workflow state should be hidden from a given set of users, you can restrict access to that state for those users by:

- Hiding all the commands in the state from the users in question.

    or

- Explicitly hiding the state itself from the users in question.

To explicitly hide a workflow state:

- Turn off the *Inheritance* for the state and do not grant *Read* access to the state to the user and all the roles assigned to the user.

    > [!note]
    > Turning off the *Inheritance* means that you must explicitly grant access to all the roles that should be able to see the state in the Workbox. This is the best approach when only a small number of users and roles need to see the state in the Workbox.

    or

- Deny the user or one of the roles that the user is assigned *Read* access to the state.

    > [!note]
    > In the Sitecore security system, deny always overrules allow. When you explicitly deny a role *Read* access, you can inadvertently prevent a user who has been assigned many roles from seeing the workflow. Denying *Read* access can have unanticipated results.

In general, we recommend that you turn off the *Inheritance* and explicitly allow access when the number of roles that require access is manageable.

## Hiding a command for certain users

The Content Editor and Workbox only displays commands for non-administrator users when:

- The user has *Write* access to the associated content item or the item is locked by the user.

    and

- The user has *Workflow State Write* access to the command’s parent state or the item is locked by the user.

    and

- The user has *Read* access to the command itself.

    and

- The user has the *Workflow Command Execute* access to the command itself.

If you configure the Sitecore security settings so that a user does not meet one of these criteria, you will hide the command from that user.

If the user must have *Write* access to both the item and the state, there are two ways to deny them *Read* access to the command.

- Turn off the *Inheritance* for the command and do not grant *Read* access to the command to the user and all the roles that the user is a member of.

    > [!note]
    > Turning off the *Inheritance* means that you must explicitly grant access to all the roles that should be able to see the state in the Workbox. This is the best approach when only a small number of users and roles need to see the state in the Workbox.

- Deny *Read* access for the command to the user or one of the roles that the user is a member of.

    > [!note]
    > In the Sitecore security system, *deny always* overrules *allow*. When you explicitly deny a role *Read* access, you can inadvertently prevent a user who has been assigned many roles from seeing the workflow item. Denying *Read* access can have unanticipated results.

In general, we recommend that you turn off the *Inheritance* and explicitly allow access when the number of roles that require access is manageable.