Also: Send Welcome Letter

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:

Thanks,

~Dean

Dean,

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.

eddie

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?)

Thanks!

Dean

So maybe all that is to ask: should I assume, at this point in the exercises, that the assignments are already routed or should I implement routing in this exercise?

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.

Hi Dean,

Please let us know for which Module and Lesson of the SAE II Self-Study Course are you trying to complete exercises?

Regards,

Henry

Pega Academy

Henry, sorry it wasn't clear, but it's in the title of my post. I'll be more careful in the future. Exercise is "Notifying Users from Within a Process" (begins on p 94 of the PDF guide)

Dean,

hang on - I'm almost done

Dean,

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

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!