Workflows: Mapping Project Start and End Dates from CRM Data
Last updated: August 27, 2026
Setting Project Dates from Your CRM Record
Category: Workflows & Automation
By default, a workflow schedules a new project's Start and End dates as an offset from the day the workflow runs — for example, "start today, end 30 days later." That works well enough until the real start and end dates already live on the record that triggered the project, like a contract start date or a go-live date on a Salesforce Opportunity. Instead of creating the project on the offset and then correcting both dates by hand, you can now map Start and End independently from fields on the triggering CRM record.
This article covers how the Project Dates card works, how to configure it, and what happens when a mapped date can't be resolved.
How It Works
In your workflow's Project Dates card, Start Date and End Date each have their own source, chosen independently:
Offset (days) — the existing behavior. The date is calculated as a number of days from when the workflow runs. This stays the default for every workflow, new or existing.
From trigger object — pick a date (or date/time) field from the record that triggered the workflow, such as a Salesforce Opportunity or HubSpot Deal. The picker only lists that object's actual date fields.
Because Start and End are configured separately, you can map just one and leave the other on an offset — for example, mapping Start to a "Contract Start Date" field while End keeps deriving from the playbook's estimated duration.
How to Configure It
Open the workflow you want to edit and create (or open) a draft.
In the flow, find and click the Project Dates card.
For Start Date, End Date, or both, switch the source from Offset (days) to From trigger object.
Use the field picker to choose the date field you want to use. The card summary updates to something like Start from Target Go-Live Date.
Save your changes and publish the workflow version when you're ready to make it live.
If the trigger object has no date fields, the picker will tell you so, and Start/End stay on the offset — there's nothing to map.
What Happens When the Workflow Runs
Both dates mapped — the created project's Start and End match the CRM values directly; the playbook's estimated duration does not override the mapped End date.
Only Start mapped — End is still calculated from the playbook's duration, anchored on the mapped Start date rather than the day the workflow ran.
A mapped date is blank or can't be read — OnRamp falls back to the offset for that date so the project is still created on schedule, and the execution log records which date fell back and why.
A mapped End date is earlier than Start — End is clamped to match Start, and the execution log notes the adjustment.
A mapped Start date still respects your playbook's "exclude weekends" setting if it's on — the actual start may shift forward from the CRM value to the next business day, the same way an offset-based start already does.
Frequently Asked Questions
Will this change how my existing workflows behave?
No. Every workflow published before this feature keeps using the offset for both dates unless you go in and explicitly switch a date to From trigger object.
What if I only want to map one of the two dates?
That's fully supported — Start and End are configured independently, so you can map either one on its own.
What happens if the CRM field is empty when the workflow runs?
The project is still created — OnRamp falls back to the offset for that date rather than failing the run, and logs why.
How do I check which source was actually used for a given project?
Open the execution in the workflow's run history — the log shows, per date, which source was configured, the field it read, the raw CRM value, and the date it resolved to.
Can I map a date/time field, or only pure dates?
Both — the picker offers date and date/time fields from the trigger object, and date/time values are normalized to their calendar date.