Hello @joellanz just to help clarify, are you saying, that in your onboarding form used through the employee onboarding module, it has a custom field labeled “e-mail” where you can enter the new employee’s email address? If so then you should be able to access those custom onboarding fields through a placeholder

As you can see in this example, these are fields that are available from one of our test forms. I could add an email custom field and access that as well.

If this workflow is to work for other situations that are not initiated from the employee onboarding module then you can use a conditional that looks to see if it is an Onboarding request (suggest looking at the service request subject line of a parent onboarding ticket, or are “Employee Onboarding Request...” so I use that to check.

If it is not that, then you can branch off and have it get the user’s details with the request email address.

Hope that helps!

Many thanks for your response. I'm aware that I can solve it the way you describe it. The problem is that I have to do a large part of the workflow twice after the condition node. once for "onboarding" and once for "standalone request". I actually wanted to avoid that. it would be easier if i could specify two fields within the payload field - maybe with an "if" query. or the possibility to fill a variable at the beginning of the workflow with a "if" statement and use that inside the payload. However, I will do it as you described. Thank you!

I agree that it can make a simple workflow very robust when we have simple alternating conditions. Luckily we now have the ability to clone nodes which expedites the process some. You could try using the Expression Builder node as a way to develop if statements but I am not sure that will alleviate the need for duplicating a chunk of the workflow. Best of luck, and feel free to share your solution as I am sure it will help others as well!