Workflow is one of my favorite features of SAP Enable Now, but a lot of clients don’t seem to use it. In this post I’ll look at why you should use workflow and how to implement a Workflow process.
First, what does Workflow do for you? In short, a Workflow process allows you to dictate what Statuses a content object should progress through during development, and in what order. More importantly, it specifies who can progress a content object from one Status to the next. It also allows content object tasks to be assigned to Authors (or SMEs, Reviewers, and so on), and provides various reports for monitoring the status of development. In short, Workflow gives you control and visibility over your content development.
Before we continue, a quick list of things it can’t do for you. Most significantly, you cannot force the use of a Workflow process for a given content object. You can set it as a default for new content objects, but there is nothing to stop an Author removing it before they set the first Status for the object. That said, the Admin will get a notification if an Author does this, so at least you know. Next, you cannot assign a Workflow task to a Role (for example, if you have a pool of Authors, any of whom could accept a recording from a SME). This means that each ‘Task processor’ needs to know the individual to whom the Task should be next assigned. Related to this, and a limitation I have requested be corrected, is that it is perfectly possible to assign a Workflow Task to a user who does not actually have the necessary permissions to perform the next required step. But assuming you can live with (or work around) these irritations, let’s see how to set up a Workflow process.
First, you need to set up the Statuses that an object will progress through, and the order in which these will occur (although the order is largely just for your reference). These are defined in the Manager, via menu option Administration > Status. You can use the predefined Statuses, rename the predefined ones, or define your own. Be careful with the wording of these – they should reflect a specific Status that the object is in. For our simple example, we will use the following statuses:
- Not started
- Ready for Editing
- Ready for Review
- Published
Note that you don’t have to use every defined Status for your Workarea in a given Workflow process, but every Status you want to use in a Workflow process must be predefined.
Once you have defined the Statuses you will use, the next step is to define the Workflow process itself. In Manager again, go to menu option Administration > Workflow, use the Quick Add section to provide a Name and Description for the Workflow process, and then click the Edit Graphically link (on the far right) for the new Workflow process.
In the Workflow Graphical Editor, select each of the required Statuses from the drop-down list and click Add, to add them to the editing area. Your screen should then look something like this:
You now need to define the transitions from one Status to the next. Transitions will be much easier for your Authors (and Reviewers/Approvers) to understand if you pick Transition names that indicate what must have happened to the content object to progress it to the next Status. For example, to progress from Not Started to Ready for Editing, a suitable Transition name might be Content created. Once you have chosen your Transition names, build out your Workflow process as follows:
- Click on the ‘from’ Status (that is, the Status the content object will be in before the Transition is executed). The selected Status block is shaded in blue.
- Click on the ‘to’ Status (that is, the Status that the content object will be in after the Transition is executed). This will normally be the next Status in your progression list, but does not have to be – a Transition can jump to any of the added Statuses. A yellow Transition block is added to the chart, with arrows coming from the ‘from’ status and going to the ‘to’ status.
- Click on the Edit button for the Transition, and in the pop-up dialog box, enter the name of the Transition. Again, choose the most logical description (from the Author’s perspective) of the Transition
- Repeat Steps 1-3 for all required Transitions.
Note that you can have multiple transitions to or from any given Status (for example, if you want an Approver to be able to create content and then push the content directly to Published) – but you can only have a single transition between any two given Statuses.
You can also have a transition that moves the content object back a Step (or several) – for example, if the Approver rejects a content object during review.
In our simple example, we’ll add three transitions to progress our content object through the process steps, and one transition to reflect a review rejection. Our Workflow process now looks something like this:
Click the Save Changes button to save your definitions, then click on the Back button to return to the Workflow screen.
The next thing to do is define who can perform each transition (and a few other things). To do this, click on the Steps link to the right of the Workflow process name. You should see a screen that looks something like this:
This screen is fairly easy to understand – it shows the Statuses in your Workflow process (this is where the order numbering is helpful), the Transitions out of each Status, and the new Status following the Transition. It also shows the role(s) that can execute this transition (in the Permission column); this will initially be Admin, but we’ll change that, below.
To change a Transition, click on the Edit (pencil) to the left of the Transition name, and in the Edit Transition dialog box, specify the following information:
- Description: This is optional, but you may want to specify the conditions for executing the Transition (such as “Simulation has been recorded by the SME and is ready for editing by the Master Author.”.
- Destination: This defaults to the Status that the content object will be in once this Transition is executed. You should not need to change this (assuming it was set correctly in the Graphical Editor).
- Permissions: Use the Edit button to select the Role(s) and/or Organizational Unit(s) that can trigger this Transition (that is, who can move the content object to the Destination Status.
- Watchers: Use the Edit button to select the Role(s) and/or Organizational Unit(s) who should be informed when the Transition is executed. The people in these roles will be sent an automated email with details of the object and the Transition, when it is executed.
- Triggers Publish State: (This is a new feature in Cloud Edition 1911.) If the content object should be automatically published as soon as this Transition is complete (and the content object is in the Destination Status) then select this checkbox. Be very careful with this option. It should only ever be selected for the final Transition in your process, and should be limited to the relevant level of authority.
Once you have defined the Transition details for each Transition, you are effectively done with the Workflow process definition and it is ready to use. However, there is one last step that you might find useful – setting this Workflow process as the default so it is always selected for new content objects. Do this as follows:
- Select menu option Administration > Workareas / Tags.
- Click on the Workflow link to the left if your Workflow process.
- In the Workflow: Edit dialog box, use the drop-down for the Wokflow field to select your Workflow process.
- Click OK.
Now, whenever anyone creates a content object within your Workarea, your Workflow process will automatically be assigned to it. (Again, as noted above, an Author could remove this, but the Admin will get a notification of this attempt to circumvent the process.) Note that a Task is always created as soon as a content object is created (so that the object can be assigned to other Authors); so a Task is already available when the Workflow process is started (by virtue of the content object being created, or by the Workflow process being assigned to an existing content object) – you do not need to explicitly create a Workflow Task for a content object.
Let’s close things out by taking a quick look at how this appears to the Author during content object development.
There are two points at which the Author can action a Workflow transition in Producer (we’ll worry about Manager another time, but if you really need to know now, it’s on the TASKS tab for the content object) – either when they Finish Editing for the content object, or by clicking on the Change Workflow button. The following screenshot shows an example of the latter:
This example is taken from the ‘review’ stage of our example development process. In this example, the current Status of the object is Ready for Review, and the Status it will be moved into is either Published (if approved) or back to Ready for Editing (if rejected). But this information is hidden from the Author (or Reviewer) – all the Author can do is select a Workflow Action (in the example above, the drop-down list for the Workflow Action has been expanded, so you can see the options available), and this is limited to only the transitions that can be executed given the current Status of the Content Object. This why it is important to choose the names of your transitions carefully – the Author just asks themselves “OK, what have just I done?” and selects the appropriate transition; everything else is then taken care of for them – selecting the next status, notifying the Watchers, and so on.
There is a little more to Workflow Tasks, both from the Author’s perspective (this is covered in detail in Chapter 5, Workflow of the SAP Enable Now Development book), and also from a reporting perspective, but that’s the subject of another post. In this one, we just wanted to see how to define and assign a Workflow process, which we’ve now done.
