Generate a New Request From a Task

New RequestAnother unique collaboration feature has been added to 4me.  This new feature makes it possible to include tasks in a change workflow that automatically register a request as soon as their predecessors have been completed.  Getting tasks to generate new requests is especially helpful for enterprises working with external providers.

These providers typically make request templates available for their customers.  Thanks to this new feature, customers can now cause requests to be generated as part of their standard change workflows by linking the request templates of providers to some of the task templates that make up their workflows.

The primary advantages are:

  1. Providers can link their request templates to one of their own change templates.  When a task from one of their customers causes a new request to be registered based on one of these request templates, a new change is automatically created in the 4me account of the provider.  The provider has complete control over the workflow of this change and does not need to ask the customer to include the individual steps in their change templates.
  2. Providers can set the targets for their request templates in the ‘Standard Service Requests’ section of the service offerings they linked to the SLAs for their customers.  The customer and the provider can therefore both see whether these targets are being met in the SLA reports.

Let’s use a simple example to demonstrate how to make use of this new capability.  If we take the Widget Data Center organization as the enterprise customer and GlobalNet as its network provider, then we can envision a scenario where the customer wants to prevent its employees from accessing inappropriate websites.  We’ll assume that GlobalNet supports this and has made the request template ‘Addition of domain to the domain blacklist’ available for its customers.

Within the Widget enterprise, all employees are allowed to notify their data center organization when an offensive website can still be accessed from the corporate network.  They can submit a request for this using Widget Data Center’s request template ‘Prevent access to website’.  Widget Data Center has linked this request template to a simple change template, which has a workflow consisting of just two task templates:

  • Service owner approval
  • GlobalNet to block traffic to website

The first task is immediately assigned to the owner of Widget’s network service.  After the service owner has approved the request, the second task needs to generate a new request for GlobalNet based on GlobalNet’s request template ‘Addition of domain to the domain blacklist’.

It is easy to configure the second task template to generate such a request whenever an actual task based on the task template reaches the status ‘Assigned’.  A change manager from Widget Data Center simply selects GlobalNet’s request template in the new ‘Request Generation’ section of the task template.

Once GlobalNet’s request template has been linked to the task template of Widget Data Center, the Service instance field becomes available to allow the appropriate service instance from GlobalNet to be selected for the requests that will be generated by the tasks that were created based on this task template.

Request template related to task template

Now that the second task template of Widget’s change template is linked to GlobalNet’s request template, it is time see how this affects the workflow for Widget and GlobalNet.

We can use a scenario where Adam Obey from the HR department submits a request using Widget Data Center’s request template ‘Prevent access to website’ after he was accidentally redirected to a website called  Because this request template is linked to the change template with the two task templates, a new change is opened and the first task is assigned to the service owner, Howard Tanner.  When Howard approves this first task, the status of the second task is updated from ‘Registered’ to ‘Assigned’.

Because the second task is linked to GlobalNet’s request template ‘Addition of domain to the domain blacklist’, a new request is generated using that template.  The new request is related to the ‘Internet Access Houston’ service instance, because that is the GlobalNet service instance selected in the task template.

As soon as the new request has been generated for GlobalNet, the status of the task is updated to ‘Request Pending’.  This status ensures that the task is not visible in anyone’s inbox.

Task that generated a new request with the status Request Pending

Because the request template of GlobalNet is linked to a change template, the new request is in the status ‘Change Pending’ and a new change is automatically generated in GlobalNet’s 4me account.

After all tasks of GlobalNet’s change have been completed, the automatically generated request for GlobalNet is set to ‘Completed’.  This causes the task that generated the request to be updated from ‘Request Pending’ to ‘Completed’.

Task that generated a new request after status was updated to Completed

Because this second task is also the last task of the change, its completion also causes the status of the change to be updated to ‘Completed’, which then automatically updates the original request from Adam to ‘Completed’.  In turn, this causes an automated notification to be sent to Adam so that he knows his request has been resolved.

Request completed automatically after completion of change

What makes this scenario a little more interesting is the fact that GlobalNet added a UI extension to its request template to collect the domain name of the website that should be blocked.  To be able to pass this piece of information automatically to GlobalNet, Widget Data Center’s request template has a similar UI extension with a field for collecting the domain name.

After preparing this UI extension, Widget Data Center added the following automation rule to the second task template to ensure that the content of their custom field ‘Domain name’ gets inserted into the custom field that GlobalNet made available for this in its request template.

Automation rule for passing custom field value to a request generated by a task

It is important to highlight the limited manual effort involved in this example scenario.  Sure, Adam had to select a request template and enter the domain name that needed to be blocked and Howard had to provide his approval.  Other than that, though, no humans were needed to complete the workflow, assuming GlobalNet used 4me’s automation rules to trigger a provisioning script that automatically added the domain name to Widget’s blacklist.