Scheduling Types

The Scheduling Type defines how the task behaves in relation to other tasks for the same asset.

Type Description
Simple Generates Work Orders at fixed intervals (based on calendar days or meter readings). Each task runs independently, regardless of other tasks.
Suppression Allows multiple related tasks to exist within the same scheduling group. When several tasks fall due around the same time, only the highest-priority task is generated, and lower-priority ones are automatically suppressed.
Cycle Links tasks in a specific sequence so that one must be completed before the next is generated (for example, Task A → Task B → Task C). This is used for progressive or conditional workflows.

How Suppression Works

Suppression helps keep your maintenance program tidy and efficient by avoiding duplicate or overlapping work.

When suppression is in use:

  • All related tasks are placed in the same Scheduling Group, such as Group A.
  • Each task in the group is given a Scheduling Priority, where 1 is the highest priority.
  • Each Scheduling Group has a configurable Scheduling Window.
  • Tasks continue to follow their usual frequency, such as every 10,000 hours.
  • If two or more tasks within the group fall inside the Scheduling Window – such as within two days or similar usage – only the task with the highest priority will create a work order.
  • Lower-priority tasks are automatically suppressed for that cycle – meaning they will not generate a work order and are also marked as completed when the higher-priority task is completed.

Example

Below is a simple structure:

Task Frequency Scheduling Group Priority Hierarchy
Engine 12,000 hours ENG 1 Main component replacement
Turbocharger 6,000 hours ENG 2 Child component replacement

In this case:

  • Both tasks exist within the same Scheduling Group, in this case "ENG".
  • The Engine task has the highest priority (value of 1) within the Scheduling Group and is due every 12,000 hours.
  • The Turbocharger task is due every 6,000 hours and has a lower scheduling priority.
  • When both tasks become due within the Scheduling Window (which a user could set to be within 90 days or 1,000 operating hours of each other):
    • Only the highest priority task in the group will generate a work order – in this case, the Engine
    • The Turbocharger task is suppressed by the Engine task

Completing the Engine task automatically also completes (resets the counter) for the Turbocharger task. Therefore, the turbochargers are due 6,000 hours (their task frequency) after the engine is replaced. In practice, replacing the engine also replaces the turbocharger as it is supplied with the new engine.

Benefits of Suppression

  • Reduces duplicate work orders for related maintenance tasks
  • Improves planning and scheduling efficiency
  • Maintains each task’s normal frequency without changing task definitions
  • Prevents double-counting of forecast costs for child tasks, improving accuracy of budgets, forecasts, and tender estimates

Limitations of Suppression

  • Suppressed tasks do not generate individual work orders for that cycle
  • Not suitable for tasks requiring independent execution or sign-off
  • May reduce visibility of lower-priority tasks in short-term schedules
  • Requires correct configuration of priorities and scheduling windows

When to use Suppression

  • When the scope of one task encompasses the scope of another task
  • Cost and resource forecasting accuracy is important for planning and tendering

When not to use Suppression

  • Tasks that must always be performed and recorded independently, such as statutory, safety-critical and compliance tasks.
  • Delaying or suppressing a task could introduce unacceptable risk

How Cycles Works

Cycle scheduling creates a repeatable sequence of tasks that run in a fixed order. Each time a task in the sequence is completed, Samurai automatically schedules the next task in the cycle. Once the final task is completed, the cycle returns to the start.

This approach is ideal when servicing follows a structured repeating pattern rather than a simple frequency.

Example 1

Hour Based Cycle

Tasks: 250 hour, 500 hour, 1000 hour, 2000 hour Interval between tasks: 250 hours

In this example, the servicing pattern repeats in a defined sequence. Instead of scheduling each task independently by its own frequency, the cycle ensures they trigger in the correct order.

The cycle runs as follows:

250 hour > 500 hour > 250 hour > 1000 hour > 250 hour > 500 hour > 250 hour > 2000 hour

Cycle returns to the start

With each work order completed, Samurai automatically advances to the next task in the sequence. This ensures the correct long term pattern of 250, 500, 1000 and 2000 hour services without overlap or duplication.

Example 2

Weekly Servicing Cycle

Tasks: 1 Week, 2 Week, 4 Week Interval between tasks: 1 week

Weekly servicing often follows a repeating rotation rather than simple multiples. Using a cycle allows you to define the exact order in which services occur.

1 Week > 2 Week > 1 Week > 4 Week

Cycle returns to the start

This pattern ensures the servicing program repeats in a predictable rhythm. Each time a service is completed, the next one in the cycle is scheduled automatically.

Benefits of Cycles

  • Ensures tasks run in the correct long-term order without manual intervention
  • Prevents missed, duplicated, or overlapping maintenance tasks
  • Simplifies scheduling by managing multiple related tasks as a single sequence
  • Automatically advances to the next task when a work order is completed
  • Reduces administrative effort compared to managing individual task frequencies
  • Ideal for maintenance programs with increasing or cumulative service intervals

Limitations of Cycles

  • Tasks automatically follow a fixed order and require manual intervention to be rearranged
  • Not suitable for tasks that need independent or irregular scheduling
  • Changes to the cycle may affect future scheduled tasks
  • Less flexible than standalone tasks for ad-hoc or reactive maintenance
  • All tasks in the cycle share the same trigger

When to use Cycles

  • When long-term maintenance patterns must be enforced automatically
  • When tasks must occur in a specific repeating sequence
  • To avoid managing multiple standalone tasks for the same asset
  • When consistency and predictability are required

When not to use Cycles

  • When tasks are unrelated or should run independently
  • For condition-based or reactive maintenance activities
  • When tasks require different trigger types
  • If task order needs to change frequently
  • For one-off or non-repeating maintenance tasks