When you move an Epic to a new quarter or reassign a Feature to a different Program Increment, its start and end dates should move with it - keeping your timeline and your planning decisions in sync.

A date alignment rule makes this happen automatically, so every timeframe change is reflected in your timeline without anyone having to update dates manually.

​

When the rule fires, it aligns the item's start and end dates to the start and end dates of the newly assigned timeframe value. The item's date span is preserved - if an item covers a 6-week window, it stays a 6-week window, with its start anchored to the beginning of the new period.

Note, that if the item's existing dates fall within the timeframe's range, no change is made when the timeframe is changed.

This rule is one-directional by design. Changing an item's timeframe triggers a date update - but changing an item's dates does not update the timeframe.

Each workspace can have one date alignment rule, covering one timeframe field. You choose whether that field is the system Quarter, Sprint, or a custom timeframe you have created.

Workspace admins can follow these steps:

Once the rule is active, any change to an item's value in that field will trigger a date update automatically. A notification bar appears at the top of the screen when the rule fires.

Because each workspace supports only one date alignment rule, it's recommended to choose the timeframe field that represents your primary planning cadence. For most teams, this will be whichever field drives your roadmap and timeline views - typically your Quarter, Program Increment, or Release.

If your team uses multiple, custom timeframe fields for different purposes (for example, one for release windows and one for stakeholder reporting), align to the one that drives your delivery timeline. The other fields can still be used for filtering and grouping without triggering date changes.

Date alignment works especially well when combined with an Inheritance rule. An Inheritance rule ensures that when you set a timeframe value on a parent item - for example, assigning an Epic to Q2 - that value automatically cascades to all child Features and Stories. The Date Alignment rule then fires on each child item as it receives the new value, aligning its dates accordingly.

The result: changing one field on a parent Epic updates the timeframe and dates across the entire hierarchy without any further manual work.

To set this up, create both rules in Workspace Settings > Automation Rules - one Inheritance rule for the timeframe field, and one Date Alignment rule for the same field. The rules operate independently but in sequence.

Timeframe fields are custom fields, so they follow the same mapping and sync behavior as other custom fields in your Jira or ADO integration - with a few caveats worth knowing before you enable date alignment.

When timeframe fields are mapped to your dev tool, there are two separate things that sync: the timeframe value itself (for example, PI1 or Q2 2026) and the item's start and end dates. Date Alignment automation affects both, and understanding how they interact prevents data surprises downstream.

In Jira, timeframe values map to fix version fields - system fix version, custom fix version multi-select, or custom multi-select. Values and their dates are carried across when first created, and new fix versions created in Jira flow back to Craft.io. After that, renaming a value on either side creates a new value rather than updating the existing one, and date edits on either side are not synced.

In ADO, timeframe values map to a text field only. The sync is one-directional - Craft.io pushes values to ADO, but ADO does not write back, and only the value label is written (e.g Q2 2026).

Item start and end dates can be mapped to date fields in Jira and ADO independently of the timeframe field mapping. When a Date Alignment rule fires and updates an item's dates, those changes push downstream if date field mapping and autosync are active - so a single timeframe reassignment can trigger a chain that ends in your dev tool.

To set up date field mapping between Craft.io and your dev tool, see Field mapping with Jira and Azure DevOps.

One rule per workspace. You can only have one active date alignment rule per workspace. If you need to switch the rule to a different timeframe field, deactivate the existing rule first and create a new one.

Multi-select timeframe fields. If you are using a multi-select custom timeframe field, the rule fires on the first value assigned to an item. Adding a second value to an item that is already aligned does not re-trigger the rule.

Deactivating the rule. You can toggle the rule off from Workspace Settings > Automation Rules at any time. Existing item dates are not changed when the rule is deactivated - it simply stops firing on future timeframe changes.
​