Comments
-
I don't know when this was fixed but I just tested this today and it works now! {{user-var.user.id}} now properly resolves to the actual user id, instead of the user's first listed group id. In this example, "user-var" is whatever your variable (your input field on your form) of type user. So if your custom field was…
-
I don't know when this was fixed but I just tested this today (3/5/2023) and it works now! {{user-var.user.id}} now properly resolves to the actual user id, instead of the user's first listed group id. In this example, "user-var" is whatever your variable is (your custom input field on your form) of type user. So if your…
-
Thanks! Tested and works great, thanks for pointing me in the right direction!
-
And of course as soon as I post that I realize what Mitch was saying - there isn't an assignee section in this case, you just use assignee_id at the level that you'd normally use the section of assignee. Which is odd because that's completely different than assigning to an email, in which case you DO nest the email in the…
-
I'm running into this same issue and unable to get it to assign the incident correctly when trying to assign to the id of a group. What was the resolution on this? I can assign with an email just fine, but neither "id" nor "assignee_id" seems to work. I've tried about every variation I can think of. The comment above…
-
My associated support case on this was initially escalated, and then later determined that this should be "feature request." I think it's clearly a bug, but I've submitted it as a feature request as advised.…
-
Thanks for the reply. I've submitted a ticket and it's been escalated. I'll post here any results.
-
Well, I think I have determined this is either a bug in SWSD or they just didn't ever build this functionality. I created a separate service request with a simple process integration to add comments to the incident. And then I put a bunch of variables and various incarnations of variable formats in the comment just so I…
-
I should note, I'm using this same {{Employee}} field in the title of the service request that gets created, and that resolves to the employee name without issue. So maybe there is a bug and this just doesn't resolve properly when a user field is used in the URL field of a process integration