New to Kestra?
Use blueprints to kickstart your first workflows.
Detect Figma shared component deletions the moment they happen and name every instance-breaking change immediately.
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.
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.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.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.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.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.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.summary logs the final counts.errors alerts Slack if the flow itself fails, for example a file key that no longer
exists or resolves to.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.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.
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.
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.| Input | Default | Purpose |
|---|---|---|
file_key |
abc123XYZ |
The Figma file to watch, from its URL |
{{ 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.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.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.name but not its stable key, so a rename alone never
shows up as a deletion; only removing the component from the file does.FIGMA_ACCESS_TOKEN and SLACK_WEBHOOK_URL secrets.file_key to a file you have edit access to and enable the trigger.log_healthy reports it under
added_keys.alert_components_deleted
names it.componentSets (variant groups) alongside individual components, since
deleting a whole set is the same hazard at a larger blast radius.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.projects.ListTeamProjects first.