Posted: 30 Mar 2015 20:55 EDT Last activity: 31 Mar 2015 17:03 EDT
Notifying Users from Within a Process: need clarification
Manager's Title in Welcome Letter
As per the prior exercise, I have added two properties related to the hiring manager: Reporting Manager and Manager Email. The scenario requires me to create a welcome letter that includes [manager's title]. I could see this being populated if exercises led us to create the Onboarding case during the Kick off onboarding step of the Candidate case but unless I am misunderstanding this is a misleading piece of data to require in the Welcome Letter. My workaround was just to ignore this (non-existent) property and merely sign the hiring manager's name via Reporting Manager property.
Notifying the hiring mananger when new assignments are pending
The scenario says "the hiring manager should be notified via email...when the assignments for requesting the new employee's assets and setting up the new employee's enablement plan are pending"
The approach says "Assignment-pending notifications should, as much as possible, be accomplished using the Notification tab on the assignment from which the notification needs to be sent" (I realize 7.1.6 doesn't have a tab, since this has been redesigned)
Under Procedure, in "Notifying users of pending assignments" section, #2 says to write the notice to the Assignee (and the message mentions "your worklist"). Normally, I would implement this by routing these assignments to the Hiring Manager, then using Notifications like this:
But we haven't implemented the Hiring Manager as a Work Party. We only have the email in .Employee.ManagerEmail so I'm unclear what to do here given how the exercise is written. Is the exercise just assuming this (above) will work because as I test the case, I am the only operator? Is this exercise testable at all?
Notifying the new employee of pending cases
Am I correct in assuming by "cases", we are still meant to use the first assignment in each case? I would use a Notification similar to my above screenshot for Benefits Enrollment, but the Payroll Setup case type is still only default steps (did I miss an exercise?) ...how was this part of the exercise intended to be completed?
In procedure, for "Sending the welcome letter to the new employee", #4 starts "Configure a Utility Shape..." and suggests using the Customer party as the new employee. But the video covers using Email Smart Shapes. If I have the employee's email in .Employee.pyEmail1 can I use this in the To field of an Email Smart Shape? Or does that field require a hard-coded actual email address (as opposed to a reference to an email)?
Did I miss where we were shown how to configure a generic Utility shape to send email? This is what I have, is it correct:
this is quite a bit on one post - so I will try and settle these one at a time.
First, re the Notify Hiring Manager when new assignments are pending use case.
What did you do for routing? Routing determines who the assignee will be, so once you have that settled, notifications to the assignee are as straight-forward as they seem - at least in this scenario.
I recognize there is nothing in SAE2 that specifically calls out setting routing details on these assignments, but SAE2 is an extension of SAE1, so all of the details required for an assignment in SAE1 are as necessary in SAE2; even if not specifically called out.
Thanks eddie, I think my point is that the exercise isn't clear to me as written, so I actually am not understanding who is performing most of the assignments. In the application walkthrough and early stage/step exercises it's not clear to me who the actors are supposed to be (it only mentions "we", unless it says "employee"), except for the two subcases which is spelled out as tasks for the employee to complete.
I've been around Pega 12 out of the past 20 years, but have been away from it for the most recent 6...so I have familiarity with the concepts of Operators, Work Parties, Worklists, Workbaskets, Pega Correspondence and routing. In other words, I think I understand HOW to do most (if not all) of what is implied by the exercise, but I'm not exactly sure WHAT is specifically implied in the exercise (full intent) and I have gone back to earlier exercises in both SAE I and II to try to understand the context of this exercise, so please bear with me :)
1) is part of the intention to have us populate a Customer work party with employee data once the "employee record"? I set up my correspondence to use the Customer party, but I don't actually have data in there as of now...is that something coming in future exercises, or is it intended that I populate that at this point?
2) Am I missing an understanding of some implied step within "Create employee record"? Because I am just populating the Employee embedded page in the case so far.
3) I can see that I have options to route assignments ToCustomer, so is it the intention that I should use that in routing the assignments to the new employee...or am I supposed to devise a different solution?
4) Does the hiring manager create the employee record?
5) I understand that because we have .Employee.ManagerEmail in the case, that is also the OperatorID for the hiring manager. Is it the intent that I use that property to actually route assignments in the case for this exercise? Or am I to assume that when Onboarding was created (because we haven't linked "Kick-off Onboarding" in Candidate to the creation of the Onboarding case yet - or should I do that now?), that the first assignment was assigned to the hiring manager, and that "current operator" aka "assignee" is *already* the hiring manager?
6) Because the email smart shape instructions specifically say to use the property reference, and not the current operator/assignee... I am not clear who is performing the assignment to create the employee record, and exactly what is supposed to be happening during this assignment that wasn't already spelled out in the exercises (which I think just has us populating the embedded page so far, yes?)
Ok, I at least now have a partially populated pyWorkParty(Customer) in Onboarding (first, last, email1), created by propagating the corresponding Employee properties during the flow action "Add Employee" (or "Create Employee Record"), so any correspondence that is already set to notify the customer by email would now have data by that point.
We left some of the steps in the case open-ended on purpose.
For example, depending on what you want to try and prove, you could confirm the Candidate case type is configured to trigger the Onboarding case type (using data propogation to map the Candidate data into the Employee data object). You would have to successfully complete a Candidate case to get started with Onboarding, and that is why we chose not to bake that option into the course. It would be a lot of work just to get to that one screen - which can be easily filled with sample data. So, that first step could go away - or maybe we keep it and use it as a "Confirm Employee Info" and some HR Rep or Recruter has to manually check the info is correct.
Or, maybe "this first iteration" is to be much simpler and all we do is build a UI for the HR rep to populate; which is basically what we have. We can make up a role for completing this task. And, going further, we could make the creation of the Onboarding case a manual thing where some operator logs into the portal and "Creates Onboarding" case. They would be presented with that first screen to fill out the employe details, so the routing on that assignment could be left at the default setting: Current Operator
Or, maybe we just wanted to have a little bit of data for a DCO Session Playback, so we might build a quick data transform to populate the .Employee data object with some sample values. Here as well, if we choose this option, we could dispense with that first human-based step completely.
Does that make sense so far?
As to the routing, I hope I am reading your posts correctly as that reading forms the basis of my response. So, forgive, and be patient with, me if I am not understanding.
"Assignee" is not for routing. Routing can be:
to the Current Operator. This is useful when we know someone is already logged in and triggers that next step we have set to route to Current Operator.
to an Operator. I'd stay away from this option as it requires you to hardcode an operator ID and that is never a good idea.
to a Workbasket. This would route the assignment to an open queue for anyone working that queue to claim
to something Custom we get to build. This allows us to get very picky about how we want to route. We can pick a worklist from here. And that is what I would do to route the assignment to the hiring manager. The hiring manager would have an operator ID, and would be assigned to an org unit. We know the employee's department, so we could use a Pega-provided router such as ToDecisionMap or ToDecisionTable. We would use either the map or the table to evaluate the department the new hire is assigned to, and from there find the appropriate operator to route to.
We would have to do the same thing for the HR Department.
As to the correspondence issues, let me make a separate post.
Am I headed in the right direction with answering your questions?
eddie, thanks for taking the time to clarify. That IS very helpful... I did look at Custom routing, but hadn't taken it as far as a decision rule option. And any time I had anything "worklist" oriented, I only had existing OperatorIDs to choose from in smart prompt and no idea how to (basically) abstract that to be a reference. Decision map or table makes sense. Thanks!