Skip to main content
Tasks

Recurring Tasks and Dependencies

Recurrence schedules and links constraining the start or end of Tasks.

Last updated 20 days ago

Schedules for recurring tasks and the interdependencies that constrain their start or completion.

Recurring Tasks

Recurrence is used for tasks that repeat regularly. If this feature is enabled:

  1. Enable recurrence when creating or editing a task.
  2. Select the repetition frequency and interval.
  3. Specify the start date and, if necessary, an end condition.
  4. Review the dates for future task instances and save.

New records are created based on the saved rule and the execution of system background processes. Whenever you modify a recurrence rule, always check which future records are affected by the change.

Task Dependencies

A dependency links tasks when one task can only be started or completed after another has been finished. On the dependencies tab, select the predecessor or successor task and the relationship type, then save.

If the predecessor task is not yet complete, the system may prevent the dependent task from starting. When there are multiple predecessors, ensure that all required predecessors are completed before manually starting the task.

Recurrence Check

After saving the rule, check the frequency, next date, and end condition on the card. A background process creates the new copy, so it may not appear immediately. Once the record appears, check the title, dates, status, and assignees, and verify that recurrence is not enabled again on the new copy.

To stop future creation, cancel the series or remove the rule. Copies that have already been created generally remain as separate records.

Dependency Types and Creation

The relationship type determines which predecessor event allows the next item to start or finish. Logic types include Start-to-Start, Finish-to-Start, Finish-to-Finish, and Start-to-Finish.

  1. Open the dependencies section.
  2. Select a predecessor or successor item.
  3. Specify the relationship type and save.
  4. Attempt to perform the restricted action.
  5. Complete the required predecessor stage and verify that the action is now permitted.

Avoid circular dependencies where items block each other directly or indirectly. In complex chains involving multiple predecessors, verify statuses manually.

Was this helpful?

Still need help? Ask the team