1. create a basic workflow, with a start and an end, and a task in the middle. For this workflow, we’ll just create a user task.
  2. Publish the workflow into teamsite
  3. define where and when the workflow can be triggered.
  4. Test the basic workflow’s trigger
  5. refine the process of the workflow by adding more tasks. 

Create a workflow

Open the workflow modeler application and get connected to teamsite (you can also work offline if you want).

You should be presented with a blank worklfow canvas, unnamed. This is what we want. If you do not have a blank workflow canvas, click on the new workflow icon.

Modify the workflow model properties. Set the name to the name of the process the workflow is supposed to help you achieve. Enter either a brief description or a description for the workflow, indicating how the process will work. Do it from the perspective of the user.

Add a start event. Modify its name property to “Start”

Add an endevent. Modify its name property to “End”. Modify its brief description to signal the conditions for the workflow to end.

Add a user task. Modify its name property, indicating the purpose of the task (e.g. doSomething). Modify either is brief description or its description, indicating the purpose of the task and how it will achieve its goal(s) (e.g. look busy, get stuff done).

Add the predecessor link(s). Modify its name. usually, indicate the outcome of the previous task, such as “printing done”, as opposed to “begin live deploy”. Some users interacting with the workflow might get scared with the next option (like, oh my god! I’m about to start what?? to send this where!?). Such users will generally be more confident with the actions they know they have completed. In the case of the start event. The “beging…” format is more acceptable when users are not involved, such as after start event or gateways.

Add the successor link(s). Modify its name property, following the same rules as for the predecessor links. Remember, this task’s successor link is another task’s predecessor…

Publish the workflow to teamsite

When your workflow is complete, the first thing is to validate it. This will ensure it can actually do stuff in sequence and not get stupidly blocked somewhere because a task does not have a successor and the end cannot be reached. Fix any errors and validate again until the message “The workflow model is valid” appears.

Publish the workflow using “File > Publish workflow”. If the workflow has not been saved, enter a name for the model when prompted. Files will get a “.ipm” extension (standing for Interwoven Process Model).

The “publish” option actually does the following:

  • uploads your workflow .ipm file in the /iwadmin/main/workflowModels/WORKAREA/iw-wa/Models folder in teamsite
  • uploads the workflow configurtation file in the workflow specific folder in /iwadmin/main/workflowModels/WORKAREA/iw-wa/Config
  • submits both files to the staging area of the /iwadmin/main/workflowModels branch.

Define where and when the worklfow can be triggered

in /iwadmin/main/workflowModels/WORKAREA/iw-wa/Internal lies a file named available_models.xml. This file indicates who can start the workflow, the events in the interface that can start the workflow (clicking on submit, invoking the menu Actions > New Job, etc.

Each workflow model should be referenced in this file in a model element. The model element has the following attributes:

  • debug: indicates if an option appears (set to true) on the instantiation form so that the workflow can be started or if instead the job specification is output for debugging.
  • active: true means the workflow is active and can be started, false means the workflow cannot be started. Users will not be able to see the workflow and start it. Existing workflows will continue as normal.
  • filename: The name of the .ipm file, without the .ipm extension.
  • name: The name as it appears to the users in the interface.

The model element also has one sub element named “allowed”. The allowed element determines the conditions under which a workflow can be triggered, such as who is using the interface, which groups or roles they belong to, where they clicked in the interface.

The command sub element of the allowed element indicates the interface event that can trigger this workflow. Valid values for the name attribute are:

  • new_job (the user clicks on Action > New Job)
  • assign (the user clicks on Action > Assign)
  • submit (the user clicks on Action > Submit)
  • tt_data (the user cliks on Next in a Data capture form to save their DCR)
  • tt_delete_dcr (the user has deleted a DCR).

the vpath-regex sub element of the allowed element indicates where in the content store the user currently is. This is a regular expression against the current vpath are specified in the regex attribute.

<model debug="false" active="true" filename="acme_process" name="acme process">
        <command name="new_job"/>
        <vpath-regex regex="/default/main/acme_www/WORKAREA/.*"/>

Modify the content of this file and submit it to Staging.

Test the basic workflow’s trigger

In content center, navigate to the correct workarea and click on the interface to trigger the workflow. If multiple workflows’ trigger conditions are met (for example, 2 or more workflows can be started by clicking on submit, the user is prompted to choose to start one of them. If only one workflow can be started, it is automatically started.

You can also modify the interface to have your own menu items invoke your workflows.

  1. Hi my friend! I want to say that this post is awesome, nice
    written and include almost all significant infos.
    I would like to peer extra posts like this .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s