Hi All,
I am trying to build a workflow which can disable account and send email to those
users.
however i can disable the accounts but unable to send email , as its not picking loop context. Can someone help on this?
Are you getting an error message, or just not seeing the email being sent? If the latter, check your email settings to see if forwarding is turned on.
Hi @nidhipriya, I’m not sure if you can pass in the email as context and the loop will keep track of what iteration you are in. Open to others to chime in if it’s possible as it would likely be simpler than below.
What you could do is put an API request in the loop that looks up the account based off the accountid, that will give you the corresponding identity, which will give you the email you are looking for to send an email. This will bypass the need for loop context.
I know this is more complex and annoying though! If you need specifics on the HTTP call to make, let me know!
Hi @nidhipriya
The email step fails because the workflow loop is iterating over accounts, but the email address is associated with the user item in the request body.
Right now:
-
Loop Input = a filtered list of accounts[…]
-
Context = $.hTTPRequest.body[*].email (this is an array of emails, not a single email per loop item)
-
Inside the loop you reference $.loop.context.email → but $.loop.context is not an object with email; it’s whatever node you set as Context.
So the loop item and the email value are not aligned.
So to fix that do the following
- Change the loop to iterate over the request body items (users), not accounts
Loop Operator
• Loop Input: $.hTTPRequest.body
• Context: (leave blank)
Now each loop iteration represents one user object that includes:
• email
• accounts
2) Inside the loop: disable the right accounts for that same user
Manage Accounts (Disable / Update)
- Select the accounts from the current loop item, e.g.:
$.loop.loopInput.accounts[?(@.accountId =~ /.*Tobedeleted.*/)].id
(Adjust the filter to match your real rule: by accountId/name/source/etc.)
- Send Email: use the email from the same loop item
Send Email
• Recipient Email Addresses: $.loop.loopInput.email.
To avoid failure do this
Before Send Email, add a quick check:
- If $.loop.loopInput.email is null/blank → skip email step
If you need account by account disable
Use a nested loop:
• Outer loop: $.hTTPRequest.body (user)
• Inner loop: $.loop.loopInput.accounts[…] (accounts)
• Send Email in the outer loop (once per user)
Hi @trettkowski
I believe Adding an API call inside the loop to “look up identity → email” is extra complexity, slower, and more failure-prone (rate limits, retries, partial failures) the email already in the original request body (based on screenshot/structure). So doing a lookup to fetch what already have is unnecessary.
I would agree that needing to put an additional call in the loop is unnecessary, but I can’t see another way to get @nidhipriya ‘s workflow to work properly.
I still think bypassing the loop context is the best solution. You could try doing $.loop.loopInput.email in the send email recipient instead and that may work without an HTTP call.
Also, you mentioned using nested loops? You cannot nest loops inside each other in ISC.
Agree on skipping an extra HTTP lookup it’s not needed here.
The clean way is to loop over $.hTTPRequest.body (users), then in the same iteration disable accounts from $.loop.loopInput.accounts[…] and send the email to $.loop.loopInput.email.
Also you’re right: ISC doesn’t support nested Loop steps, but we don’t need nesting since Manage Accounts can take the filtered list of account IDs in one shot.
@amrdodani- unfortunately its still not working .. only disabling accounts is successful but email is not triggering
Hi @nidhipriya
1: Can you download the workflow JSON and then share it? Please mask any sensitive data or your tenant related info.
2: If you set the loop context to this $.hTTPRequest.body[*].email then try changing the recipient email address value to $.loop.context
OR
If you set the the loop context to this $.hTTPRequest.body then try changing the recipient email address value to $.loop.context.email
1 Like
Hello @nidhipriya ,
In the “step Input“ of loop operator, are you able to see the “email” attribute? Could you please send the screenshot of that?
For example, if I want to get email from below object, my JSON path will be like
$.loop.context.getAccounts.accounts.attributes.EmpEmail
@ThejaC - I am not using get accounts, to fetch account ID, I am using a search query and identifying accountID and disabling accounts
Got if. Can u check the context object in step input? at starting of step input. Is the email attribute just inside of context or its inside of any other object?
Hi @nidhipriya
since Manage Accounts succeeds, your loop + disable logic is OK. The issue is the Send Email step isn’t getting a resolved recipient.
In the workflows, when you want the recipient to come from JSONPath at runtime, the Send Email step needs the dynamic mapping in the workflow JSON, e.g.:
- recipientEmailList.$ : “$.loop.loopInput.email”
(or $.loop.loopInput.attributes.email if that’s where your email lives)
If you type $.loop… directly in the UI, it can be treated as a literal string (not evaluated), so Send Email ends up with no valid “to” address.
Also: leave From blank unless you’ve verified it (otherwise send can fail), and add a quick condition to skip Send Email when email is null/blank.
If you share the exported workflow JSON (mask tenant details), we can point to the exact field/path to use.
{
“context.$”: “”,
“input”: [
{
“_type”: “identity”,
“_version”: “v2”,
“accounts”: [
{
“accountId”: “”,
“id”: “”,
“name”: “”,
“source”: {
“name”: “”
}
},
{
“accountId”: “”,
“id”: “”,
“name”: “”,
“source”: {
“name”: “”
}
},
{
“accountId”: “”,
“id”: “”,
“name”: “”,
“source”: {
“name”: “”
}
}
],
“email”: “sxy@gmail.com”,
“id”: “yyyy”,
“name”: “xyz”,
“type”: “identity”
},
@ThejaC - here is the step input , I see email is outside
@amrdodani - PFA
workflowjson.txt (3.0 KB)
Add a guard condition before Send Email:
- Only send if $.loop.loopInput.email is not null/empty.
This prevents failures/noise and confirms quickly if the issue is “missing email value” vs “tenant email service”.
So i brief
Two things to try next:
1- add a condition to skip Send Email when loopInput.email is null/empty, and 2- confirm tenant outbound email is enabled/allowed (otherwise sp:send-email will fail even with a valid recipient).
Send the exact error from the Send Email step output to check whether it’s tenant email config vs recipient/policy.
Workflow looks good. $.loop.loopInput.email should work. Can you check if “Test Address“ is selected and valid email address has been given in email settings? Hope you are testing this in sandbox.
@ThejaC - I did make the changes in email settings , i am receiving mail to the test address that i mentioned
So, when you change it to intended recipients, it’s not working. May be last suggestion, can you change the variable to just “$.loop.context“ in recipients email and see if it works? Becoz, in context we already giving the variable as $.hTTPRequest.body[*].email
@JackSparrow - I tried with loop context as well, but no luck..
Can i use get identity and fetch their email and try inside the loop