How to Identify that a Change Requests was Created in the Self Service Portal

In the end user portal, end users can create Incident Requests (IR) and Change Requests (CR). The incidents created in the portal automatically have a “Source” property which is filled in with “Portal.” Change Requests on the other hand do not have this property. If you would like to isolate Change Requests which were created in the portal for purposes like triggering a workflow, creating a view, sending a notification, etc… you should follow the procedure below. The procedure in this blog illustrates how to create a hook which can be used to identify that a Change Request was created in the portal. Notice that the names can be anything you would like, and in the case below the names are just examples.

It is important that the procedure be followed closely since some actions can have undesired effects.

We will accomplish the isolation of Change Requests from the portal by using a template for Change Requests which sets the Change Category to “Portal.” If you have other Change Request templates which change the Change Category, make sure to read and understand the “You would like to apply a template…” sections below. These section assume that you have already gone through the procedure to isolate the Change Requests that were created in the portal.

You would like to apply a template to all CRs which does not change the Change Category.

Example Scenario:

All Change Requests with Impact = Major should be assigned to Al Young.

In this case, the CRs that were created in the portal will keep the “Portal” Change Category. The template will make the desired changes (assign to Al Young) to all Change Requests which match the specified criteria (Impact = Major), including the ones that were created in the portal. To have the template targeted at all Change Requests, target the Change Management Class when creating the workflow, view, notification, etc…

The image above shows which Change Requests the template will be applied to.

Note that since the “Portal” Change Category was not changed, you will still be able to trigger based on Change Category = Portal.

You would like to apply a template to all CRs which does change the Change Category.

Example Scenario:

All Change Requests with Impact = Major should be have the Change Category modified to “Major Change Request”.

In this case, the CRs that were created in the portal will no longer keep the “Portal” Change Category. The template will change the Change Category to “Major Change Request” and you will not longer be able to trigger workflows, views, notifications, etc… based on Change Category = “Portal”

The image above shows which Change Requests the template will be applied to.

Note that since the “Portal” Change Category was changed, you will no longer be able to trigger based on Change Category = Portal. If the category is changed unintentionally it will be hard to find this Change Request. To avoid this happening unintentionally see “You would like to apply a template to all non-portal CRs.”

You would like to apply a template to all portal CRs which does not change the Change Category.

Example Scenario:

All Change Requests created in the Portal with Area = Application should be assigned to Phil Otten.

In this case, the CRs that were created in the portal will keep the “Portal” Change Category. The template will make the desired changes (assign to Phil Otten) to all change requests which match the specified criteria (Area = Application AND Change Category = Portal). This means that change requests that were not created from the portal but are Area = Application will not be assigned to Phil.

The image above shows which Change Requests the template will be applied to.

Note that since the “Portal” Change Category was not changed, you will still be able to trigger based on Change Category = Portal.

You would like to apply a template to all portal CRs which does change the Change Category.

Example Scenario:

All Change Requests Created in the Portal with Area = Security should be have the Change Category modified to “Security Change Request”.

In this case, the CRs that were created in the portal will no longer keep the “Portal” Change Category. The template will change the Change Category to “Security Change Request” and you will not longer be able to trigger workflows, views, notifications, etc… based on Change Category = “Portal.” If this is the desired outcome then there is no problem with the fact that this happened.

The image above shows which Change Requests the template will be applied to.

Note that since the “Portal” Change Category was changed, you will no longer be able to trigger based on Change Category = Portal. If the category is changed unintentionally it will be hard to find this Change Request. To avoid this happening unintentionally see “You would like to apply a template to all non-portal CRs which does change the Change Category.”

You would like to apply a template to non-portal CRs

Example Scenario:

All Change Requests, except those created in the Portal, with Area = Network should be assigned to Al Young.

In this case, the CRs that were created in the portal will keep the “Portal” Change Category. By using the “Change Category Not Equal Portal” criteria, it ensures that Change Requests which were created in the portal are not affected by the application of this template.

The image above shows which Change Requests the template will be applied to.

Note that since the “Portal” Change Category was not changed, you will still be able to trigger based on Change Category = Portal.

Procedure for Creating and Configuring the Portal Change Category.

Navigate to Library\Lists and double-click the Change Category list.

Add a new list value by pressing Add Item, title it “Portal” and press OK.

Go to the Activities tab and remove all of the activities that you do not want to be applied to all change requests coming in from the portal.

NOTE: You will need to create a new template for “Standard Change Request.” The reason that you cannot just create a new template for the portal is since the portal is wired directly into the Standard Change Request template, so we have to convert this template to the portal change request template. You should probably document what these activities contain before deleting them since this information will be needed later when creating the new Standard Change Request Template. Note that you will also have to change all your workflows which applies the old Standard Change Request template to apply the new Standard Change Request Template.

Go to the Template tab, under category select the “Portal” category list item which was created in a previous step. This will provide a hook for workflows, views, subscriptions, etc… when building a criteria.

Create a new Template for Standard Change Requests. Go through the Change Request workflows and make sure that the workflows which used to apply the old Standard Change Request template (this is the template that was converted into the Portal Change Request template, and should be titled as such) are changed to apply the new Standard Change Request template. Another place to check is workflow deployment processes (if you are using Self Service Software Provisioning) as they apply templates too.

Now after this has been done, when you are creating a workflow, view, or subscription, you can use the category property to build your criteria and use the “Portal” value as way to identify the Change Requests that were created in the Portal.