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

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