Handling Activities
The problem I have, and maybe you too, is no matter how easy I make the process, it's never easy enough. I just got people to start using email approvals for tickets, because logging into the Cireson portal and then clicking the Activities tab and then finding the proper Review Activity is to much to ask. I was thinking of linking the approvals directly to the RA from email to circumvent the extra mouse clicks, but the Cireson portal does not directly link to activities.
What other solutions are out there in an ever increasing "one-click" world?
Best Answers
-
Adrian_Mataisz Customer Advanced IT Monkey ✭✭✭You can point directly to the RA from the email: http://yourwebsite.com/ServiceRequest/Edit/SR#/?tab=activity&activityId=RA#
But I agree user approval experience should be easy and clear. on the portal4 -
Conner_Wood Customer Ninja IT Monkey ✭✭✭✭For my work, I am in the process of building a Reviewer Portal using C# MVC format. It only uses Windows Authentication (which means no login screen) and using impersonation on the connected user I am able to have them connect to the SCSM SDK code which then allows a quick way to view their RA's, leave a comment on the top parent main ticket, and Approve or Reject the RA like they would on the Cireson Portal/SCSM Console.
However email will always remain a communication tool, so emails are sent out when:- A request is created -- Sent to Requester and Authorizing Manager notifying Authorizing Manager review will be required shortly after initial processing.
- RA is reached and becomes In-Progress -- Time-Check Reminders from the RP using cache item callbacks with a direct link to the RA on the RP.
- RA is approved -- Email Requester, Authorizing Manager, and potentially assigned user/support group
- RA is rejected -- Close WorkItem, email requester and authorizing manager
Whether I'll be allowed to share this with the community once completed is another issue.
Side-Note:
I know that you could potentially pre-format your emails to already open the Cireson Portal on the Activity tab and point to the correct RA, however it's tricky because if you make the notification criteria in the SCSM Console you then have to export the MP to narrow the relationship to a ticket type, since the link contains "ChangeRequest" or "ServiceRequest" so you need a notifcation + notification criteria for each type of ticket with a review:
Ex.
[SCSM Console > Administration > Notifications > Templates]
You create a notification "CR - Review Activity In Progress" with Review Activity being the targeted class and has the following code to link directly to RA in a CR on your Cireson Portal.<p><a href="https://portal.contoso.com/<b>ChangeRequest</b>/Edit/$Context/Path[Relationship='CustomSystem_WorkItem_Activity_Library!System.WorkItemContainsActivity' SeedRole='Target' TypeConstraint='WorkItem!System.WorkItem']/Property[Type='WorkItem!System.WorkItem']/Id$?activityId=$Context/Property[Type='WorkItem!System.WorkItem']/Id$&tab=activity">Click here to view the RA of the Change Request on the Web Portal</a></p>
[SCSM Console > Administration > Workflows > Configuration > Activity Event Workflow Configuration > Review Activity]
Create new event like "CR - Review Activity - In-Progress" and in Specify Criteria section:- Changed From == [Activity]Status does not equal In Progress
- Changed To == [Activity]Status equals In Progress AND Has Parent Work Item [Work Item]ID is not empty
This MP contains the following references among others, you will need to update yours accordingly:<Reference Alias="WorkItem"> <ID>System.WorkItem.Library</ID> <Version>7.5.3079.607</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference> <Reference Alias="CoreChange"> <ID>System.WorkItem.ChangeRequest.Library</ID> <Version>7.5.3079.0</Version> <PublicKeyToken>31bf3856ad364e35</PublicKeyToken> </Reference><br>
Now for the Criteria to ensure the Parent Ticket is a Change Request<UpdateInstance> <Criteria> <Expression> <And> <Expression> <SimpleExpression> <ValueExpression> <Property State="Pre">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']/Status$</Property> </ValueExpression> <Operator>NotEqual</Operator> <ValueExpression> <Value>{11fc3cef-15e5-bca4-dee0-9c1155ec8d83}</Value> </ValueExpression> </SimpleExpression> </Expression> <Expression> <And> <Expression> <SimpleExpression> <ValueExpression> <Property State="Post">$Context/Property[Type='CustomSystem_WorkItem_Activity_Library!System.WorkItem.Activity']/Status$</Property> </ValueExpression> <Operator>Equal</Operator> <ValueExpression> <Value>{11fc3cef-15e5-bca4-dee0-9c1155ec8d83}</Value> </ValueExpression> </SimpleExpression> </Expression> <Expression> <UnaryExpression> <ValueExpression> <Property State="Post">$Context/Path[Relationship='WorkItem!System.WorkItemHasParentWorkItem' <b><i>TypeConstraint='CoreChange!System.WorkItem.ChangeRequest'</i></b>]/Property[Type='WorkItem!System.WorkItem']/Id$</Property> </ValueExpression> <Operator>IsNotNull</Operator> </UnaryExpression> </Expression> </And> </Expression> </And> </Expression> </Criteria> </UpdateInstance><br>
And there you have it, obviously the Alias in your MP have to match up correctly for your criteria and notifcations, I personally recommend to have all of these RA Notification/Notification-Workflows in a single unsealed MP called something like "My.ReviewActivity.PortalNotifications"3
Answers
But I agree user approval experience should be easy and clear. on the portal
However email will always remain a communication tool, so emails are sent out when:
- A request is created -- Sent to Requester and Authorizing Manager notifying Authorizing Manager review will be required shortly after initial processing.
- RA is reached and becomes In-Progress -- Time-Check Reminders from the RP using cache item callbacks with a direct link to the RA on the RP.
- RA is approved -- Email Requester, Authorizing Manager, and potentially assigned user/support group
- RA is rejected -- Close WorkItem, email requester and authorizing manager
So far I've had almost 3 weeks worth of actual time spent into this, and I am about ~40% of the way there. Mostly using Sessions with a slight amount of javascript for the initial table of RAs to click from to open the correct Review View.Whether I'll be allowed to share this with the community once completed is another issue.
Side-Note:
I know that you could potentially pre-format your emails to already open the Cireson Portal on the Activity tab and point to the correct RA, however it's tricky because if you make the notification criteria in the SCSM Console you then have to export the MP to narrow the relationship to a ticket type, since the link contains "ChangeRequest" or "ServiceRequest" so you need a notifcation + notification criteria for each type of ticket with a review:
Ex.
[SCSM Console > Administration > Notifications > Templates]
You create a notification "CR - Review Activity In Progress" with Review Activity being the targeted class and has the following code to link directly to RA in a CR on your Cireson Portal.
[SCSM Console > Administration > Workflows > Configuration > Activity Event Workflow Configuration > Review Activity]
Create new event like "CR - Review Activity - In-Progress" and in Specify Criteria section:
- Changed From == [Activity]Status does not equal In Progress
- Changed To == [Activity]Status equals In Progress AND Has Parent Work Item [Work Item]ID is not empty
Under Select People to Notify section, choose your notifcation that uses ChangeRequest as part of url. ex. "CR - Review Activity In Progress" and have users set as Reviewers then click add to put it in Notification list. Once you save this Workflow, you must export the MP it belongs in and alter the criteria to match your parent ticket type. In this case I add a type constraint of CR to the WorkItemHasParentWorkItem Relationship.This MP contains the following references among others, you will need to update yours accordingly:
Now for the Criteria to ensure the Parent Ticket is a Change Request
And there you have it, obviously the Alias in your MP have to match up correctly for your criteria and notifcations, I personally recommend to have all of these RA Notification/Notification-Workflows in a single unsealed MP called something like "My.ReviewActivity.PortalNotifications"
Change Request -> Sequential/Parallel Activity --> Review Activity
You would need to create another Notification + WF Notification Pair to get the CR Ticket at X level since SCSM doesn't handle recursion with a relationship.
But hopefully no one will ever do that.
The correct relationship from Activity to WorkItem should be "CoreActivity!System.WorkItemContainsActivity". This can be verified by looking at a SCSM Tickets History and seeing the relationship class is logged as "Contains Activity".
Which means you need to reference another alias
My apologies to anyone who has struggled due to using the incorrect relationship. I cannot believe I didn't spot it when I originally posted that long explanation.
deep links to activities can actually be done like this:
http://serviceportal.doman.local/Activity/Edit/MA#
So you don't have to provide the parent (top parent) work item for the link. You might need to provide it for other information inside the email, but that's another thing.
Newer portal versions introduced "activity pages". You can access special review activity page including all relevant details with highlighted review buttons: https://portalFQDN/ReviewActivity/Approval/RAID