GetFile icon
Get icon
OutputValues icon
Switch icon
Log icon
SlackIncomingWebhook icon
Set icon
FileUpdated icon

Figma Shared Component Deletion Drift Gate

Detect Figma shared component deletions the moment they happen and name every instance-breaking change immediately.

Categories
Infrastructure

Figma has no warning dialog for deleting a component that other files depend on. The delete just succeeds, and every file with an instance of that component finds out later, quietly, the next time someone opens it and notices the instance has detached from its source. There is no Figma-native alert for this, no changelog entry a team lead can subscribe to. This blueprint watches a specific file for real edits, keeps a running snapshot of its component keys in Kestra's own KV store, and the moment an edit removes one that was there before, names exactly which component (and its last known name) is gone, immediately, instead of whenever someone happens to notice a detached instance downstream.

This blueprint was created by Mohit Jeswani.

How it works

  1. on_file_updated (io.kestra.plugin.figma.triggers.FileUpdated) polls the file's lastModified timestamp every 5 minutes and fires only when it actually advances, using the trigger's own watermark state; the first poll after enabling just records a baseline.
  2. fetch_current_components (io.kestra.plugin.figma.files.GetFile) pulls the file's current document, which includes a top-level components map keyed by node id, each entry carrying the component's stable key and current name.
  3. load_known_components (io.kestra.plugin.core.kv.Get) reads back the component key list this flow saved after the previous edit; missing on the very first run for a given file, which every downstream expression treats as an empty baseline.
  4. diff_components (io.kestra.plugin.core.output.OutputValues) computes the current key set and the previous key set with jq, then the set difference in both directions: deleted_keys (present before, gone now, the dangerous direction) and added_keys (new since the last edit, informational), classifying the result as HEALTHY or COMPONENTS_DELETED.
  5. route (io.kestra.plugin.core.flow.Switch) alerts Slack by name for every deleted component on COMPONENTS_DELETED; there is no remediation branch, because Figma's REST API has no way to restore a deleted component, only a human re-creating it in the editor.
  6. save_current_components (io.kestra.plugin.core.kv.Set) always runs, saving the current key set as the new baseline so the next edit is diffed against this one, not re-alerting on the same deletion forever.
  7. summary logs the final counts.
  8. errors alerts Slack if the flow itself fails, for example a file key that no longer exists or resolves to.

What you get

  • A deletion alert the moment it happens, naming the exact component instead of leaving every downstream team to notice a detached instance on their own and trace it back.
  • A real diff, not a snapshot: added components are reported separately from deleted ones, so a big refactor that both removes and adds components does not read as pure breakage.
  • A baseline that survives in Kestra's own KV store between polls, so this works as a standing watch on a shared design-system file, not a one-off comparison.

Who it's for

  • Design systems and platform teams who maintain a shared Figma component library that other product files consume, and want to know the instant something downstream broke.
  • Teams evaluating the Figma plugin who want a worked example of triggers.FileUpdated combined with cross-run state in core.kv, distinct from this repo's existing Figma blueprint, which watches comment backlog rather than the file's actual design content.

Why orchestrate this with Kestra

Figma has no built-in alert for "a component this file's downstream consumers depend on was just deleted." Kestra turns the file's own lastModified signal into a real content diff, keeps the component baseline in its KV store between runs so there is no separate database to stand up, and keeps a full execution history of every edit this flow has seen and exactly what changed.

Prerequisites

  • A Figma personal access token (Account Settings > Personal access tokens) scoped to at least file read access, for the account that can see the target file.
  • A Slack incoming webhook URL.
  • The file key segment from the target file's URL.

This blueprint only calls Figma's hosted REST API and Kestra's own KV store; nothing needs to run locally beyond a Figma account and a file you can point it at. A free Figma account and a personal file are enough to exercise every path: add a component, let the trigger fire and confirm log_healthy, delete it, and confirm alert_components_deleted names it.

Secrets

  • FIGMA_ACCESS_TOKEN: used by both on_file_updated and fetch_current_components. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_FIGMA_ACCESS_TOKEN.
  • SLACK_WEBHOOK_URL: used by the alert case and the errors block. In Kestra OSS, provide it as SECRET_SLACK_WEBHOOK_URL.

Inputs

Input Default Purpose
file_key abc123XYZ The Figma file to watch, from its URL

Outputs

  • {{ outputs.diff_components.values.severity }}: HEALTHY or COMPONENTS_DELETED.
  • {{ outputs.diff_components.values.deleted_keys }} / .deleted_names: the stable keys and, where still resolvable, the names of components removed since the last edit this flow saw.
  • {{ outputs.diff_components.values.added_keys }}: component keys new since the last edit.

Pitfalls

  • GetFile's response includes the whole document tree alongside components; on a very large file this can be a sizeable payload even with fetchType: FETCH_ONE. For a file with hundreds of pages, consider fetchType: STORE and a follow-up parse task instead.
  • deleted_names can only name a component by looking it up in the CURRENT response, which by definition no longer contains a deleted component; it falls back to the bare deleted_keys list whenever none of the deleted keys could be resolved to a name, which is the normal case for a genuine deletion, not a bug.
  • The KV key is scoped to file_key only, not to this flow's namespace or id beyond that; watching the same file from two differently-named copies of this flow sharing one Kestra instance's KV store will have both overwrite the same baseline.
  • Renaming a component changes name but not its stable key, so a rename alone never shows up as a deletion; only removing the component from the file does.

Quick start

  1. Add the FIGMA_ACCESS_TOKEN and SLACK_WEBHOOK_URL secrets.
  2. Set file_key to a file you have edit access to and enable the trigger.
  3. Add a new component, wait for the next poll, and confirm log_healthy reports it under added_keys.
  4. Delete that component, wait for the next poll, and confirm alert_components_deleted names it.

How to extend

  • Extend the diff to componentSets (variant groups) alongside individual components, since deleting a whole set is the same hazard at a larger blast radius.
  • Cross-reference styles (shared color/text styles) the same way; a deleted shared style silently reverts every consumer to a hard-coded value instead of detaching visibly.
  • Post the Slack alert to the specific channel a design-system team actually watches by looking up the file's owning team via projects.ListTeamProjects first.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.