Best Of

I saw this the other day on the main/larger thread but saw a couple of responses that kinda covered things. But I'll cover them here as well:

• Custom Events are really only documented in so far as name and the descriptions contained therein for those functions. The repo has a handful of very direct examples. Some functions contained in the custom events script also feature verbose explanations of variables such as when using Custom Rules
• Per my cited comment above, while powerful. Custom Events create the opportunity to bring the connector to a grinding halt if written incorrectly. All in all, its a fine line of - yes these exist and you can use them, but its undertaken entirely at your own risk as everyone's custom events could be different and I/others would have no way of quick and easily troubleshooting.
• When it comes to debugging Custom Events. You'll need to open the SCSM Console, head over to Adminstration → Settings → SMlets Exchange Connector settings. In there, you'll go the workflow tab and disable the workflow then save. The connector is now no longer running. On the SCSM server, or using a run as account - you'll need to open PowerShell ISE or VSCode. Then open up the smletsExchangeConnector.ps1 script. Run it. This now gives you a first hand experience of the connector running and you can watch what errors (if any) arise. More importantly, you can breakpoint the Invoke-AfterCreateIR function and step line by line through it to verify your logic. You don't have to do this and should be a last resort if your custom log events aren't telling you what you're expecting

Now with all of that said. Your function at a high level makes sense for what you want to do. What's worth calling out here is when you're in a Custom Event. Log where at all possible for your own troubleshooting. Second, make sure to include a default case in your switch statement so when things don't go to plan you have a path AND event as to why. Take the following example:

$email = "problem on four, attn: user1"

switch -wildcard ($email) {
  "*user1" { write-output "The assignee is user1. Log info event." }
  "*user2" { write-output "The assignee is user2. Log info event." }
  default { write-output "Not sure who the assignee should be. Log warning event." }}

But a couple of things worth pointing out in the context of the function you are in:

$ID = $NewWorkItem.ID ### I am guessing here based off custom events examples
    $SRClass = Get-SCSMClass -name System.WorkItem.ServiceRequest$
    $UserClass = Get-SCSMClass -name System.Domain.User$
    $AssignedToUserRelClass  = Get-SCSMRelationshipClass -Name System.WorkItemAssignedToUser$
    $ServiceRequest = Get-SCSMObject -Class $SRClass -Filter "ID -eq $ID"
    #Maybe I could use $newWorkItem instead of doing the $serviceRequest lookup on the ID?

Your guesses are correct but $ID, $SRClass, $UserClass $AssignedToUserRelClass, and even $ServiceRequest are all already known when you are in the function

• Your function can simply make use of the $newWorkItem variable as you commented
• The classes $SRClass, $UserClass ($domainUserClass in the case of the connector), and $AssignedToUserRelClass are set by the connector. Check out things in the primary script starting around line 800. You'll see a host of common variables that you can use if necessary to avoid redeclaring them
• The function is Invoke-AfterCreateIR, but you're using a Service Request based class. Either you're in the wrong function, or this was a copy paste mistake. In any case, it's all the more reason to use the $newWorkItem variable as its Id, Class, etc. are all known, and exist contextually. Which means the nature of your function can not only be trimmed down significantly, but the core logic of what you're trying to do is really just what's in your switch statement