Workflow states are shown on content objects in the state drop-down at the top right, in the green border on content you have permission to edit. The items in the menu are the transitions you can use between workflow states. For example, to move from the visible (default) to the published state, you use the publish transition. State transitions can have guards based on roles (only members in a certain role in the current context can execute the transition - for example, only Managers and Reviewers are permitted to use the publish transition in the default Plone workflow), permissions or arbitrary expressions. Each content type either has no workflow (rare) or has exactly one workflow associated with it. This is set via the portal_workflow tool. The Contents tab of this tool in the ZMI shows the currently installed workflows. You can add or modify workflows via this GUI, adding states (remember to set a default state!), transitions and the allowed transitions between states. More documentation on the DCWorkflow engine can be found on zope.org.

The workflow engine will manage a certain number of permissions and set them correctly when the state of an object is changed. You should rarely, if ever, need to change permissions at the "Security" tab. Instead, you change them in the workflow associated with the folder or content type in question. This is the mechanism which allows several different content objects to re-use the CMF core permissions. For example, the Anonymous role has the View permission in the published state, but not the visible state. Note that if you modify a workflow's permissions-in-state mapping, the changes will not affect existing objects automatically. You must update the security settings by clicking Update security settings at the bottom of the Workflows tab in portal_workflow in the ZMI.

Thus, workflows serve a dual purpose - to represent the evolution of a piece of content, from creation (the initial state), through a review cycle (if there is one), to a final state, and to control the permissions to the content in each state. If you have particular needs, you can create a new workflow (usually based on an existing workflow), set up the states and transitions necessary, make the workflow manage a certain set of permission and set the role-to-permission mapping for those permissions in each workflow state. Using role or permission guards on transitions, you can then control who is at liberty to alter the permissions. For more details on how to use the DCWorkflow engine, read its documentation.