I am trying to automate a process where when a lead comes in , a welcome email is sent, and time based workflow for subsequent emails send throughout the day. The welcome email, and all subsequent emails should be sent from the Lead Owner, which is set via assignment rules. This is currently accomplished manually by the lead owner doing a field update and firing workflow that way.

The issue I am running into is that if I allow the workflow to be triggered via something I do in Apex, the "Current User" that the emails will come from will be a system account since the leads are coming in via web-to-lead. From my research I can accomplish the initial email via an @future method and specifying the reply-to as the lead owner, and the display name as a static Org Wide address, which gives me some control.

Is there anything I am not thinking of that would be a solution to trigger a workflow rule on a lead insert, and have some control over the "Current User" value that will be set as the Sender/Reply To in the email workflow alerts?

Thanks I am banging my head against the wall with this one...

1 Answer 1


If you are looking to use workflow rules to send the email then as far as I can tell you should be all set. Looking at the order of execution, the assignment rules should be applied before the workflow rules.

On the server, Salesforce:

Loads the original record from the database or initializes the record for an upsert statement.

Loads the new record field values from the request and overwrites the old values.

If the request came from a standard UI edit page, Salesforce runs system validation to check the record for:

Compliance with layout-specific rules

Required values at the layout level and field-definition level

Valid field formats

Maximum field length

Salesforce doesn't perform system validation in this step when the request comes from other sources, such as an Apex application or a SOAP API call.

Salesforce runs user-defined validation rules if multiline items were created, such as quote line items and opportunity line items.

Executes all before triggers.

Runs most system validation steps again, such as verifying that all required fields have a non-null value, and runs any user-defined validation rules. The only system validation that Salesforce doesn't run a second time (when the request comes from a standard UI edit page) is the enforcement of layout-specific rules.

Executes duplicate rules. If the duplicate rule identifies the record as a duplicate and uses the block action, the record is not saved and no further steps, such as after triggers and workflow rules, are taken.

Saves the record to the database, but doesn't commit yet.

Executes all after triggers.

Executes assignment rules.

Executes auto-response rules.

Executes workflow rules.

If there are workflow field updates, updates the record again.

If the record was updated with workflow field updates, fires before update triggers and after update triggers one more time (and only one more time), in addition to standard validations. Custom validation rules and duplicate rules are not run again.

Executes processes.

If there are workflow flow triggers, executes the flows.

The Process Builder has superseded flow trigger workflow actions, formerly available in a pilot program. Organizations that are using flow trigger workflow actions can continue to create and edit them, but flow trigger workflow actions aren’t available for new organizations. For information on enabling the Process Builder in your organization, contact Salesforce.

Executes escalation rules.

Executes entitlement rules.

If the record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the parent record. Parent record goes through save procedure.

If the parent record is updated, and a grandparent record contains a roll-up summary field or is part of a cross-object workflow, performs calculations and updates the roll-up summary field in the grandparent record. Grandparent record goes through save procedure.

Executes Criteria Based Sharing evaluation.

Commits all DML operations to the database.

Executes post-commit logic, such as sending email.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .