When a Job sends an email notification, the message always comes From the sender name configured on the Job (or the environment, if one is not explicitly set in the Job). The Reply To address, however, is set automatically based on the type of Job and the action that triggered it. This article explains that logic so you know what to expect when a recipient hits "reply."
The Reply To address determined automatically using the rules below and is not currently configurable.
Quick reference
| Job trigger | Reply To is set to |
|---|---|
| Created | The user who created the record. If the record was created through a public/magic link, the environment administrator. |
| Moved | The user who was assigned to the record before the move occurred. If the record was unassigned at that point, the environment administrator. |
| Assigned | The user who performed the (re)assignment. |
| Field Update | The user who directly edited the field, if a person made the change. If the change came from another automation (e.g., an API call or another Job), the environment administrator. |
| Due Date | The environment administrator. |
| Fixed (scheduled) | The environment administrator. |
"Environment administrator" refers to a system address in the format admin+[environment name]@logicgate.com. This mailbox isn't monitored by LogicGate or your organization and replies sent to it won't reach anyone.
Created Jobs
Reply To is set to the user who created the record. If the record was created by an external/anonymous user through a public step (e.g., a magic link form), Reply To falls back to the environment administrator, since there's no internal user to attribute the action to.
Moved Jobs
Reply To is set to whoever was assigned to the record immediately before the move happened — not the user who performed the move, and not the user the record gets reassigned to as part of that move.
If the record had no assignee at the time of the move, Reply To falls back to the environment administrator.
Example: Record is assigned to User A. User B submits the record, moving it to the next step and reassigning it to User C in the process. Reply To on that notification will be User A, the assignee before the move, not User B (who moved it) or User C (the new assignee).
Assigned Jobs
Reply To is set to the user who performed the reassignment regardless of who the record was assigned to before or after. This is different from Moved Jobs, where the prior assignee is used instead of the person taking the action.
Example: User C reassigns a record from User A to User B. Reply To on that notification will be User C.
Field Update Jobs
Reply To depends on what caused the field to change:
- If a person directly edited the field (e.g., through the record UI or a table report), Reply To is set to that user.
- If the field changed as a result of another automation (such as an API call, a linked/triggered record action, another Job, etc.), then there's no individual user to attribute the change to, so Reply To falls back to the environment administrator.
Due Date Jobs
Due Date jobs run on a schedule (when a due date or SLA period elapses) rather than in response to a specific user's action, so Reply To is always set to the environment administrator.
Fixed (Scheduled) Jobs
Like Due Date jobs, Fixed jobs run on a schedule rather than being triggered by a user action. Reply To is always set to the environment administrator.
Key takeaway
Reply To reflects whichever user's action is considered responsible for triggering the notification — or, when no specific user can be identified, the environment administrator mailbox. This behavior is automatic and can't currently be changed or removed from Job email notifications.