Skip to content

[feature]: Unify integration actions into the automation engine #9048

@rudacs

Description

@rudacs

Is there an existing issue for this?

  • I have searched the existing issues

Summary

Today, integrations such as GitLab and GitHub have their own specific configuration for actions like changing a work item state based on Pull Request or Merge Request events.

This works for simple use cases, but it limits the potential of integrations.

The proposal is to separate the integration setup from the workflow behavior:

  • Integrations should only connect external systems and expose events.
  • Plane Automations should define what happens when those events occur.

This would make integrations more flexible, reusable, and consistent across different tools.

Why should this be worked on?


Current behavior

Currently, when configuring an integration, some automation behavior is configured inside the integration itself.

Example:

  • Connect GitLab
  • Connect GitHub
  • Configure automatic state changes directly inside the integration settings
  • The integration decides which actions are available

This creates a limited model because each integration needs to implement its own specific automation behavior.


Proposed behavior

Integrations should only handle:

  1. Authentication
  2. Connection setup
  3. Event ingestion
  4. Event normalization
  5. Exposing available triggers to Plane Automations

Plane Automations should handle:

  1. Conditions
  2. Actions
  3. State transitions
  4. Field updates
  5. Comments
  6. Notifications
  7. Webhook calls
  8. Work item linking
  9. Any future workflow behavior

Main idea

Instead of configuring behavior like this inside the GitLab or GitHub integration:

When a Merge Request is opened, move the work item to In Progress.

The user should configure it inside Plane Automations:

When GitLab Merge Request is opened
and the Merge Request references a Plane work item
then move the work item to In Progress.

This would make integrations more powerful and consistent.


Example automation rules

When a GitLab Merge Request is opened
and the title contains a Plane work item ID
then move the linked work item to In Review.
When a GitLab Merge Request is merged
and it references a Plane work item
then move the linked work item to Ready for QA.
When a GitHub Pull Request is merged
and it references a Plane work item
then move the linked work item to Done
and add a comment with the Pull Request link.
When a GitLab Merge Request pipeline fails
and it references a Plane work item
then add a comment to the linked work item.
When a commit references a Plane work item ID
then add the commit link to the work item activity.
When a Pull Request is merged
and the linked work item has the label hotfix
then notify a specific channel.
When a GitLab issue is created
then create or update a Plane work item.

Why this would be better

This would create a single automation model across all integrations.

Instead of having isolated behavior inside each integration, Plane would have a unified workflow engine that can react to events from different systems.

This would also make future integrations easier to support because each new integration would only need to expose events. The automation engine would already know how to handle conditions and actions.


Benefits

  • Unified automation model
  • Less duplicated logic inside each integration
  • More flexible workflows
  • Better separation between integration setup and business rules
  • Easier support for future integrations
  • More powerful GitLab and GitHub workflows
  • Better support for teams with custom processes
  • Possibility to automate more than only state changes
  • Consistent behavior across GitLab, GitHub, Slack, Discord, email, webhooks, and other integrations

Metadata

Metadata

Assignees

Labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions