SAP Knowledge Base Article - Public

2087739 - Single Sender and Single Recipient | How They Work and Setting Them Up in SuccessFactors

Symptom

  • How can I change the Sender of SuccessFactors notifications?
  • Is it possible to change the "FROM" name or email for the SuccessFactors notifications?
  • Can I customize the SuccessFactors sender name and email for all notifications?
  • Is it possible to set a Single Sender & Single Recipient for email notifications?
  • How to change system e-mail notifications sender's name from "System System"
  • How to avoid end users from receiving any notification from SuccessFactors
  • How to disable all the instance's notifications
  • I'd like to test some notifications and therefore disable them for the users
  • How to temporarily send all the SuccessFactors notifications to a single email address

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

SAP SuccessFactors HXM Suite

Resolution

What is the Single Sender feature?

  • SuccessFactors has a standard Sender for all the HXM Platform Notifications, which is "System System (system@successfactors.com)".
  • However, some customers may wish to customize it in order to be more friendly to end users or even to match the Company identity.

Note: Sometimes, customer's firewall settings can also see the standard sender as "spam", so, it's also a reason that could motivate the change.

  • If it happens, asking your IT to allow our sender server IP address can also be helpful to you. Check out KB article 2087468 for further reference.
  • By taking this action, you'll ensure all SuccessFactors notifications will be allowed by your firewall/mail security application as they're external incomes.

This change can be done through the Single Sender feature. It's possible to change either the Sender's name and/or email address.

Example: You can switch from the standard System System (system@successfactors.com) to Example Company (beaware@example.com)

Important: The domain set in the Single Sender's email address must be valid. If you set a dummy email in there, all instance notifications will stop being delivered.

Note: Enabling this feature requires Provisioning access. Please reach out to your Implementation Partner to have the necessary changes made. If you don't have a partner, proceed as below:

  1. Reach SuccessFactors Support using component LOD-SF-PLT-NOT via chat or Support Incident
  2. Within your description, add the preferred name and email address.
    • Single Sender Name: it can be any string and will be the shown Sender's name, such as "Example Company" from the previous example.
    • Single Sender Email: The email address, with a valid domain, you'd like to appear as "FROM" in the notifications, such as "beaware@example.com" from the previous example.

Important: Be careful to not choose some switch which may end up defining a real user's email as the Single Sender:

Example: Rewrite of the domain only (which isn't permitted) by changing johndoe@abc.com to johndoe@successfactors.com

    • Second John's email could be a real user in SuccessFactors, and therefore this approach would result in our employees getting your emails when people reply to John.
    • Finally, this could lead to a scenario where our SuccessFactors company users would receive your emails. It would be, besides other reasons, a huge security breach.

Important: This setting won't affect any email notification workflow, sending and receiving settings nor any other thing. It's only about Sender's looking.

What is the Single Recipient feature?

  • Sometimes customers may have a internal testing project requiring end users do not receive email notifications.
  • An example could be hiring, promotion or termination tests. It wouldn't be good for an end user to receive such notifications.
  • The purpose of Single Recipient is to help in these situations. When active, all notifications will be delivered to a single email's inbox instead of users.
  • From there, should you wish and have a capable system, you can determine the subject of and whom to send the email to.

Note: Enabling this feature requires Provisioning access. Please reach out to your Implementation Partner to have the necessary changes made. If you don't have a partner, proceed as below:

  1. Reach SuccessFactors Support using component LOD-SF-PLT-NOT via chat or Support Incident
  2. Within your description, add the preferred name and email address.
    • Single Recipient Name: this can be any string, just like the Single Sender.
    • Single Recipient Email: this will be the email address where all the notifications will be delivered to.
    • The Single Sender email address must be valid, otherwise, all the notifications go no where.

Extra: If the company have different domains for different department or business unit, customer might want turn on Single Recipient feature for only some domains,  and for emails of other domains should still receive their notifications in the meantime. Customer could provide us a coma-separated list with the domains that should go to Single Recipient in field of Forward email addressed to these domains only (comma separated)

Example: example-sales.com, example-it.com, example-hr.com

    • As a result, all the notifications sent to Sales, IT and HR will be forwaded to Single Recipient address.
    • Notifications sent to other domains will be sent to original email address directly.

Important: Single Recipient and Single Sender are totally independent of each other and can be used alone or in combination.

See Also

KB article 2087468 - Emails Blocked or Not Delivered Due to Spam Filters, Spoofing, Bombing (mass mail), IP Allow Lists

Keywords

sf, success factors, bizx, biz x, e-mail, stop notifications , KBA , sf email notifications , LOD-SF-PLT-NOT , Email Notifications , LOD-SF-PLT-PRV , Provisioning Changes , How To

Product

SAP SuccessFactors HXM Suite all versions