Request a New Content Item

In this example, we'll take a look at a standalone workflow that can be used to request the creation of a new content item. This workflow can be launched and will route a task to an editorial group (or a specific editorial user). The editor will create the content item, fill in its properties and then submit it to complete the workflow.

This example demonstrates integrated email as well as the usage of Script Workflow Handlers to execute custom scripts. These scripts are used to create new content, attach it to your workflow and modify properties on those documents.

In this case, we'll assume that the content item being created is of type my:article. The my:article content type has the following schema:

{
    "_qname": "my:article",
    "_type": "d:type",
    "type": "object",    
    "properties":{
        "title": {
            "type": "string"
        },
        "body": {
            "type": "string"
        }
    }
}

Here is the workflow model:

{
    "id": "request_new_content_item",
    "title": "Request a New Content Item",
    "nodes": {
        "start": {
            "type": "start",
            "transitions": {
                "start": "edit"
            },
            "handlers": {
                "LEAVE": [{
                    "type": "script",
                    "config": {
                        "script": "var masterNode = branch.create({'title': 'Sample Title', '_type': 'my:article'}); workflowTask.addDocument(masterNode);"
                    }
                }]
            }                            
        },
        "edit": {
            "type": "participant",
            "title": "Editor works on requested content",
            "swimlane": "editors",
            "transitions": {
                "approve": "complete",
                "cancel": "cancel"
            },
            "email": "pending"
        },
        "complete": {
            "type": "passthru",
            "title": "Complete",
            "transitions": {
                "next": "end"
            },
            "email": "complete"
        },
        "cancel": {
            "type": "passthru",
            "title": "Cancel",
            "transitions": {
                "next": "end"
            },
            "handlers": {
                "ENTER": [
                    {
                        "type": "script",
                        "config": {
                            "script": "for (var i = 0; i < documents.length; i++) { documents[i].del(); }"
                        }
                    }
                ]
            },
            "email": "cancel"
        },
        "end": {
            "type": "end"
        }
    },
    "swimlanes": {
        "editors": {
            "principals": []
        }
    },
    "emails": {
        "pending": {
            "body": "A new task has arrived in your task inbox: <a href='{{workflowTask.url}}'>{{workflowTask.url}}</a>",
            "subject": "A request was received for new content"
        },
        "complete": {
            "body": "The following documents were produced:<br/>{{#each workflowTask.documents}}<a href='{{workflowTask.url}}/documents/{{_doc}}>{{title}}</a>{{/each}}",
            "subject": "Your request for new content was completed"
        },
        "cancel": {
            "body": "The cancelled task can be viewed here: <a href='{{workflowTask.url}}'>{{workflowTask.url}}</a>",
            "subject": "Your request for new content was cancelled"
        }        
    }
}

How it works

1. The workflow model begins in the start state.
2. It immediately transitions to the step1 state.
3. The step1 state is of type participant and so it requires user interaction to continue. The workflow will wait in this state until a user who belongs to the approver swimlane triggers one of the transitions.
4. If the approve transition is triggered, the workflow advances to the approve state. Otherwise, if the reject transition is triggered, the workflow advances to the reject state.
5. Both the approve and reject states are of type passthru. They simple advance the first available transition and go to the end state.
6. The end state is of type end and so it ends the workflow.

Notes

This workflow intentionally leaves the editors swimlane empty. The user who launches this workflow will be prompted to provide one or more principals to occupy the swimlane. The swimlane could be occupied by a single user, multiple users, a group, many groups or any combination of the aforementioned.

In practice, you may want to pre-assign this swimlane to one or more groups or users. Assignments consist of strings containing the domainId and principalId. They are specified like this domainId/principalId.

Anyone who is a member of the editors swimlane will have the option to work on the workflow when it is in the edit state.

If the editors swimlane has exactly 1 user, the user will be auto-assigned to edit. On the other hand, if the editors swimlane has multiple users or groups, the participant state identified by edit will not be auto-assigned. Instead, a member of the swimlane will need to first Claim the Task.