During the Project Stage, the Eightfold Team has set up a mechanism they called “Loop Back Email” in Sandbox instance. With this mechanism, whenever a Candidate has created an account in PCS, an email will be triggered to 4 users of the project team - not to the Candidate. This is because Sandbox was a controlled instance, we didn’t want anyone else to get emails.
Now that we have completed the project, we want to stop these emails from being sent to these 4 users, as these users have moved out of project. We also want these emails to be sent to a Group Mailbox we have created. This way, we still have a method of checking email triggers when Candidates create account in Sandbox PCS.
Please let me know how this Loop Back Email Setup works. Is it possible for the System Admin user to access this Loop Back Email setup in Sandbox instance?
If there is any documents on this, that will be helpful too.
Thanks in advance.
Best answer by dkreiger
Hi @arulsubra, The “Loop Back Email” setup is a sandbox email-safety mechanism. It is not a separate PCS workflow; it is controlled by the sandbox email loopback gate and the instance’s email configuration.
In sandbox / efdemo instances, Eightfold prevents most outbound emails from being delivered to real external recipients. This is to avoid test emails being sent to actual candidates or users. When loopback is enabled, outbound emails are redirected or suppressed based on the email context and the configured recipient lists.
For PCS candidate flows, the key settings are:
loopback_whitelisted_recipient_emails Use this when specific test recipient email addresses should receive the email as the intended recipient. Only the intended whitelisted recipient receives the email; the email is not sent to every address in the list.
default_loopback_admin_emails This is the fallback list. If the system cannot identify an eligible admin/test recipient, emails intended for non-whitelisted recipients are sent to the addresses in this list instead. This is likely the configuration currently sending emails to the 4 project users.
To stop emails from going to the 4 project users and route them to your group mailbox instead, the expected change is to remove those 4 users from default_loopback_admin_emails and add the group mailbox there. This will preserve a way to monitor sandbox email triggers without sending those test emails to former project users.
A couple of important notes:
The group mailbox should be a valid, monitored mailbox or distribution list.
default_loopback_admin_emails can receive a high volume of fallback sandbox emails, so it should be used carefully.
Login, password reset, and verification emails have special handling and may be sent to the intended email address to support account-verification testing.
Older sandbox behavior also noted that emails in the “To” field are generally blocked from reaching real candidates, while intentionally added CC/BCC recipients may be delivered.
Regarding System Admin access: the configuration is maintained in the sandbox email config JSON, under the email configuration page. If the System Admin has access to the relevant Admin / Integrations email configuration area, they should be able to review or update these values. If they do not see this configuration, Eightfold Support / the implementation team can assist by updating the email config for the sandbox instance.
Helpful internal documentation:
Email loop back gate in Sandbox and efdemo instances — Confluence page covering the current loopback behavior, loopback_whitelisted_recipient_emails, and default_loopback_admin_emails.
How Sandbox environment notification works — older sandbox notification behavior overview.
Mail Notification Testing in Sandbox — sandbox email testing guidance, including how -sandbox emails are looped back to real inboxes in some cases.
Hi @arulsubra, The “Loop Back Email” setup is a sandbox email-safety mechanism. It is not a separate PCS workflow; it is controlled by the sandbox email loopback gate and the instance’s email configuration.
In sandbox / efdemo instances, Eightfold prevents most outbound emails from being delivered to real external recipients. This is to avoid test emails being sent to actual candidates or users. When loopback is enabled, outbound emails are redirected or suppressed based on the email context and the configured recipient lists.
For PCS candidate flows, the key settings are:
loopback_whitelisted_recipient_emails Use this when specific test recipient email addresses should receive the email as the intended recipient. Only the intended whitelisted recipient receives the email; the email is not sent to every address in the list.
default_loopback_admin_emails This is the fallback list. If the system cannot identify an eligible admin/test recipient, emails intended for non-whitelisted recipients are sent to the addresses in this list instead. This is likely the configuration currently sending emails to the 4 project users.
To stop emails from going to the 4 project users and route them to your group mailbox instead, the expected change is to remove those 4 users from default_loopback_admin_emails and add the group mailbox there. This will preserve a way to monitor sandbox email triggers without sending those test emails to former project users.
A couple of important notes:
The group mailbox should be a valid, monitored mailbox or distribution list.
default_loopback_admin_emails can receive a high volume of fallback sandbox emails, so it should be used carefully.
Login, password reset, and verification emails have special handling and may be sent to the intended email address to support account-verification testing.
Older sandbox behavior also noted that emails in the “To” field are generally blocked from reaching real candidates, while intentionally added CC/BCC recipients may be delivered.
Regarding System Admin access: the configuration is maintained in the sandbox email config JSON, under the email configuration page. If the System Admin has access to the relevant Admin / Integrations email configuration area, they should be able to review or update these values. If they do not see this configuration, Eightfold Support / the implementation team can assist by updating the email config for the sandbox instance.
Helpful internal documentation:
Email loop back gate in Sandbox and efdemo instances — Confluence page covering the current loopback behavior, loopback_whitelisted_recipient_emails, and default_loopback_admin_emails.
How Sandbox environment notification works — older sandbox notification behavior overview.
Mail Notification Testing in Sandbox — sandbox email testing guidance, including how -sandbox emails are looped back to real inboxes in some cases.
