This section covers the plugin's Rock Automation integration: triggers that watch project and task activity, plus the plugin-specific event used to create a project from a template. Use these pages when you want projects and tasks to participate in larger automated workflows.
Automation is what lets the Project Management plugin do more than store work. With the triggers and event described in this section, projects and tasks can participate in reminders, escalations, notifications, intake processes, follow-up workflows, and lightweight command-style interactions. If you already use Rock workflows, this section is the bridge that lets project activity become one more signal those workflows can react to.
Most setups will use these automation components in a simple pattern: choose the trigger that best matches the project or task event you care about, then connect it to one or more Rock events such as Launch Workflow or Send Communication. The plugin adds only one first-class event of its own, Create Project From Template, because that scenario needs a purpose-built configuration surface.
What Ships
The pages below are grouped by the kind of question you are trying to answer. If you care about state changes, start with lifecycle triggers. If you care about who now owns the work, start with assignment triggers. If you care about lateness over time, use the overdue trigger. If your process begins with someone commenting on a project, use the comment trigger.
Common Concepts
A few ideas show up across almost every trigger in this section, so it helps to keep them in mind before you start configuring automations.
- Merge fields. Every trigger passes merge fields into its events. The exact fields vary by trigger, so each trigger page documents the values it exposes and how they are useful downstream.
- Project Type filtering. Many triggers can be limited to a single project type. On task-based triggers, that often means the parent project's type rather than the task alone.
- Rock controls the event pipeline. Events on the same trigger can run in any order and may run in parallel. If step B must wait for step A, place both steps inside one workflow rather than wiring multiple sibling events.
- Detection scope is plugin-owned. These triggers observe changes made through the plugin's blocks, workflow actions, helpers, and jobs. Direct SQL, imports that bypass Rock's save pipeline, or third-party code paths that do not go through the plugin may not fire them.
- Use the most specific trigger you can. In most cases, the plugin's named triggers are easier to understand and safer to configure than a more generic change-detection approach.