Admin Legacy Automation

Admin legacy automation

Overview

This skill is the admin persona's companion to v1.3's coverage extension of sfi.get_impact. v1.3 does not introduce a new headline tool — it makes the existing impact graph aware of nine new ComponentTypes (WorkflowRule, ApprovalProcess, AssignmentRule, AutoResponseRule, EscalationRule, DuplicateRule, MatchingRule, EmailTemplate, Letterhead) and one new EdgeType (sendsEmail). The admin's first-line question for these types is "what does this rule do?", "what emails fire when X happens?", or "is this still active in our org?" — and the honest answer is to walk the edges the extractors emit from XML and present them as a structured rule → action → target timeline.

The graph consumes one new EdgeType and reuses three existing ones. The new edge is sendsEmail (a rule declares it will send the named EmailTemplate; direction: {WorkflowRule | ApprovalProcess | AutoResponseRule} → EmailTemplate, confidence: declared). The reused edges, all declared in v1.3's emission set, are triggersOn (rule → parent CustomObject), references (rule → action target or approver or assignee or matching rule), and parentOf (one-file-many- rules container relationship from CustomObject to each per- rule node). The boundary that matters for admins: v1.3 lists what's configured, it does not simulate runtime. Workflow rule criteria, time-dependent actions, approval routing per record, and duplicate fuzzy-match decisions all need record-level data v1.x doesn't have. The skill surfaces this gap explicitly rather than fabricating an evaluated answer.

When to fire

Fire this skill on legacy-automation phrasing. Concrete triggers:

• "What workflow rules touch / fire on object Y?" — "what workflow rules touch Account?", "which workflows fire on a Case update?", "show me the workflows on Opportunity.".
• "Which approval processes are still active?" — "which approval processes are active on Opportunity?", "list the approval processes for Account.", "are the discount approvals still in use?".
• "What assignment rule routes Cases / Leads?" — "what's the assignment rule for Lead?", "how does Case routing work?", "show me the lead-routing rules.".
• "Is this workflow being replaced by a flow?" — "should I migrate Notify_Sales_On_New_Tier1 to Flow?", "is this workflow legacy?", "what do I lose if I move this rule to Flow?".
• "Which fields does this duplicate rule check?" — "what fields does DuplicateRule:Account.Standard_Duplicate compare?", "show me the matching rule behind the lead duplicate check.".
• "What emails go out for this approval / rule?" — "which email template fires when the discount approval is submitted?", "what auto-response goes out for a web lead?", "which approvals send the Sales/WelcomeEmail template?".
• "Show me the auto-response rules for Lead / Case." — "what auto-responses do we have on Lead?", "list the autoresponse rules.".
• "What's the escalation chain on Case?" — "show me the escalation rules for Case.", "what queue does P1 escalate to?", "when does a P1 case escalate?".
• "Which rules use the {TemplateName} email template?" — inversion question; walks the sendsEmail edge in the in direction.
• "What does this letterhead get used by?" — leaf-node usage query; walks the references edge inward to EmailTemplate nodes.
• "Why did this account get assigned to this queue?" — the configuration answer is the AssignmentRule that names the queue; the record-level answer needs live data and is out of scope. Surface both halves.
• "What's the criteria for this rule?" — surface the extracted criteria count from wherever that family puts it (node property on WorkflowRule; per-entry EDGE property on AssignmentRule / AutoResponseRule; absent entirely on EscalationRule) plus the rule's formula where present. The evaluation of the criteria against a record needs record-level data and is out of scope.

When NOT to fire

Defer to another skill when:

• The user asks "what breaks if I change X?" — cross-component impact analysis. Defer to architect-impact-analysis → sfi.get_impact. (That skill already walks the v1.3 edges; it just frames the answer for architects rather than admins.)
• The user asks "why can't user X see this record?" — visibility, not automation. Defer to admin-sharing-troubleshooting → sfi.why_cant_user_see_record.
• The user asks "what layout does user X see?" — page-layout routing. Defer to admin-page-layout-routing → sfi.layout_for_user.
• The user asks "where is this field used in Apex?" — code-side reference question. Defer to developer-apex-refactor → sfi.find_code_usages.
• The user asks "what does this flow do?" — Flow narration is outside v1.3 (and outside the legacy-automation skill regardless; Flow is the modern automation tier). Defer to business-user-orientation's process-explanation intent, which refuses to narrate Flow XML as English. If the user wants to know whether a workflow rule has been replaced by a Flow on the same object, this skill can help — list both and call out that the workflow rule is still active per its <active>true</active> property.
• The user asks for record-level evaluation ("does this workflow rule actually fire on Account 001xx12345?", "is this approval process triggered for this specific opportunity?"). v1.3 lists what's configured; it doesn't simulate execution. Refuse honestly; direct the admin to Setup → Workflow Rules or Setup → Approval Processes in the Salesforce UI, or to a live sf data query against their org.
• The user wants to refresh, init, or check vault status. Fire refreshing-the-org-vault, /sfi-init, or pre-flight-checks.
• The user names an automation type outside v1.3's nine — OutboundMessage, WorkflowTask, OrgWideEmailAddress, or Process Builder as a standalone type (Process Builder is metadata-shaped as a Flow, covered by v0.1's Flow extractor). Say so plainly and name the boundary; offer the closest partial if one exists (e.g., the rule's action references the outbound message by name even though the OutboundMessage node itself isn't extracted).

Steps

Walk these in order. Each step has a definite output that feeds the next.

Step 1 — Parse the question into (object, automation-type, [rule-name])

The user almost never types a canonical id. They say "the workflows on Account", "the discount approval", "the lead auto-response". Translate to one or both of:

• A type-scoped enumeration when the user asks "which / what / show me" — translate "the workflow rules on Account" to (type: 'WorkflowRule', parentId: 'CustomObject:Account').
• A specific rule id when the user names a rule — translate "the Notify Sales workflow" to a search call, then to WorkflowRule:Account.Notify_Sales_On_New_Tier1 (the canonical form). The format per type is:

EmailTemplate is the outlier — its canonical id keys off the template's folder, not an object (templates live under email/{Folder}/{Template}.email-meta.xml). Letterhead is a leaf node with zero outgoing edges (it has no references to anything; only EmailTemplates reference it).

If the user names a rule by display label rather than API name ("the discount workflow"), call sfi.search_components({ query: 'discount workflow', types: ['WorkflowRule'] }) to translate before firing the impact tool. Don't guess — workflow rule names are bespoke per org. A canonical id that matches nothing at all now returns error.kind: 'component-not-found' rather than an empty slice, but an id that resolves to the WRONG component still answers confidently about that component, and nothing in the payload will say so.

If the user supplies a record-level shape ("does the discount approval fire on opportunity 006xx12345?"), refuse the record- level half and translate to the configuration question explicitly: "I can tell you what ApprovalProcess:Opportunity. Discount_Approval is configured to do — entry criteria, approver chain, email templates. v1.x can't tell you whether that specific record would trigger it; check the record's Approval History related list in Salesforce for that."

Step 2 — Enumerate or fetch the target node(s)

For type-scoped enumerations, call sfi.list_components:

{ "type": "WorkflowRule", "parentId": "CustomObject:Account" }

This returns every WorkflowRule:Account.* node sorted by id. Surface the list with each rule's active property (read from properties.isActive or properties.active on the node) so the admin can immediately see which rules are live and which are inactive but still extracted.

For specific rule queries, call sfi.get_component with the canonical id to fetch the node's full properties (criteria formula, action list, business-hours reference, etc.) before walking edges. This gives the timeline its context.

Step 3 — Walk the impact / edge graph

For a rule-impact question ("what does this rule touch?"), call sfi.get_impact with the rule's id:

{ "componentId": "WorkflowRule:Account.Notify_Sales_On_New_Tier1", "hops": 2 }

The response carries impact.nodes (the rule plus everything it touches) and impact.edges. Walk the edges and bucket by edgeType:

• triggersOn — the parent object the rule fires on.
• references — the rule's action targets (named WorkflowAlert / FieldUpdate / OutboundMessage / Task, approver Role / Group / User, assignee Queue / User, matching-rule pointer from DuplicateRule).
• sendsEmail — the EmailTemplate the rule's alert / notification step sends.
• callsApex — when a WorkflowRule action invokes an Apex class via a <flowTrigger> / <workflowAction> of type Apex, the edge points at the named ApexClass.
• parentOf — the container relationship from CustomObject:{Object} to each per-rule node; mostly scaffolding, but surface it once for the record so the admin knows the parent is CustomObject:Account (or whichever).

For an inversion question ("which rules send this email template?"), use sfi.get_edges:

{
  "nodeId": "EmailTemplate:Sales.WelcomeEmail",
  "direction": "in",
  "edgeType": "sendsEmail"
}

The response lists every WorkflowRule, ApprovalProcess, or AutoResponseRule node with an outgoing sendsEmail edge into the named template. Sort by rule type for legibility.

For an approver chain question ("who approves the discount process?"), use sfi.get_edges:

{
  "fromId": "ApprovalProcess:Opportunity.Discount_Approval",
  "direction": "out",
  "edgeType": "references"
}

The response lists every references edge to a Role, Group, User, or Queue named in <approvalSteps>[*].<assignedApprover>. Walk the list in step order (the extractor preserves it) and present each step with its label and approver.

Step 4 — Follow sendsEmail to the EmailTemplate body

When a rule has a sendsEmail edge, the natural follow-up question is "what does that email actually say?" Call sfi.get_component on the EmailTemplate id and surface:

• properties.subject — the email's subject line, verbatim.
• properties.templateType — text, html, visualforce, or custom. (The XML element is <type>; the extracted property is templateType. There is no properties.type.)
• There is no properties.body and no properties.content. The extractor does not store the body string at all — it stores properties.bodyLength, a character count (always 0 for visualforce templates, whose body lives in the referenced VF page). If the admin needs the body text, point them at the source file, or read it via the sourcePath on the node.
• Merge tokens ARE tokenized. The v3.0 body-merge scan parses the <content> body for {!Object.Field} and conditional {!IF(... Object.Field ...)} merges. Each distinct field yields a references edge with confidence: 'parsed', properties.role: 'body-merge', properties.mergeContext (the verbatim {!...} token) and properties.conditional. The node mirrors this as properties.mergeFields (canonical CustomField: ids) and properties.referencedObjects. Do NOT tell the admin merge tokens are un-tokenized — surface the resolved fields.
• properties.richTemplateSyntaxDetected — true when at least one merge appeared inside a function call. When true, disclose the real boundary: the field REFERENCES are captured; the FIRING LOGIC of the conditional is not.
• properties.letterheadName — the named Letterhead, if any. (The XML element is <letterhead>; the extracted property is letterheadName. There is no properties.letterhead.)

If the template's properties.letterheadName is non-null, the EmailTemplate node has a references edge to the named Letterhead. Surface the letterhead's name for context; don't walk further (Letterhead is a leaf — top/bottom/header colors and styling, nothing more).

Step 5 — Present as a structured timeline

The raw response is a flat list of nodes and edges. The human reading needs a grouped timeline: rule → trigger → criteria → actions → targets. Walk the rule's edges and present in this order:

1. What it is. Rule type, canonical id, parent object, active property. Surface inactive rules explicitly — they're still extracted, but the admin needs to know "this rule is in the metadata but active: false."
2. When it fires. Trigger type for WorkflowRule (onCreateOnly, onAllChanges, etc.), entry criteria for ApprovalProcess (formula text or criteriaItems), action timing for EscalationRule — read minutesToEscalation off the rule's outgoing references / sendsEmail EDGES, which is where the extractor puts it; it is NOT a node property. Do NOT report escalationStartTime: the extractor validates it (against the real Salesforce enum, CaseCreation / CaseLastModified — no other value exists) but does not store it, so the vault cannot tell you which one a rule uses. Say so rather than guessing. actionOnInsert / actionOnUpdate for DuplicateRule.
3. Criteria summary. Surface the criteria count from the RIGHT place for the family (WorkflowRule: properties.criteriaItemCount; AssignmentRule / AutoResponseRule: the per-ruleEntry criteriaItemCount on the outgoing references / sendsEmail edge; EscalationRule: unavailable — say so) plus properties.formula where it exists. There is no properties.criteriaItems node property on any of them. Do not evaluate the criteria — that's record-level. The admin reads the predicate themselves.
4. Actions. Bucket by action category (Alert / FieldUpdate / Apex / OutboundMessage / Task for WorkflowRule; initialSubmission / finalApproval / finalRejection / recallActions for ApprovalProcess; escalationAction[] for EscalationRule; ruleEntry[] for AssignmentRule / AutoResponseRule). For each action, name the target via its references or sendsEmail edge.
5. Targets. For each action target, cite the canonical id (EmailTemplate:Sales.WelcomeEmail, Queue:Tier2_Support, MatchingRule:Account.Account_Name_And_Domain, etc.) and the confidence (always declared for v1.3 emission).
6. Disclosure. "v1.3 lists what's configured; doesn't simulate runtime."

Do not silently drop steps. An inactive rule, an empty action list, a dangling action target — they're all signal. The admin's trust hinges on every extracted edge appearing in the report.

Step 6 — Honest disclosure when an edge dangles

The v1.0 graph store tolerates dangling edges. When a WorkflowRule action references a target the extractor cannot resolve — e.g., the rule's <fieldUpdates>[*].<field> names Region__c but CustomField:Account.Region__c is not in the extracted set — the edge is emitted with the target id intact and the consumer sees "target not in extracted set" when walking.

Surface this verbatim, never silently drop it:

The workflow rule's fieldUpdate references CustomField:Account.Region__c, which is not in the extracted set. Either the field has been removed from the org since the last refresh, the field name was renamed in metadata and the workflow points at the old name, or the extraction missed it. Verify in Setup → Object Manager → Account → Fields.

This is the v1.3 honesty anchor (Q35). The dangling edge is evidence, not a footnote — it's how the admin learns that the workflow rule is pointing at a field that no longer exists in the expected place.

Step 7 — Append the v1.3 boundary disclosure

Every response from this skill ends with the fixed-form boundary disclosure (next section). When the response surfaces a dangling edge, restate it; otherwise it appears once at the end.

Step 8 — When the question is migration-shaped, add the Flow recommendation

If the admin asked "should I migrate this workflow to Flow?", "is this workflow legacy?", or "what would I lose by moving this to Flow?", walk the impact chain first so the migration conversation has the full dependency picture. Then add the migration paragraph:

Salesforce has superseded WorkflowRule and Process Builder with Flow for most use cases. Workflow Rules are in the multi- release retirement track (retirement began in 2024+); Process Builder is already retired. v1.3 still extracts WorkflowRules honestly because real orgs still ship them in production — but when planning changes, consider whether the rule should move to Flow before extending it. Migration considerations grounded in the impact chain above:

• Every references / sendsEmail / callsApex target listed above must be reproduced in the new Flow.
• Time-dependent workflow actions (<workflowTimeTriggers>) require Scheduled Paths in the migrating Flow.
• The criteria predicate translates to a Flow start condition or a Decision element.
• The Salesforce Migrate to Flow tool (Setup → Workflow Rules → Migrate to Flow) handles most cases mechanically; complex Time-Dependent Actions may require manual rewrite.

The migration disclosure is a footer, not a replacement for the impact analysis. An admin planning a migration without the full target list will produce an incomplete Flow.

Reporting format

Use the synthetic-v1.3 fixture for the worked example. Suppose the admin asks:

"What workflow rules touch Account?"

Claude's flow:

1. Parse → (type: 'WorkflowRule', parentId: 'CustomObject:Account').
2. Enumerate via sfi.list_components (illustrative):

{
  "data": {
    "components": [
      {
        "id": "WorkflowRule:Account.Notify_Sales_On_New_Tier1",
        "type": "WorkflowRule",
        "properties": {
          "active": true,
          "triggerType": "onCreateOnly",
          "criteriaItemCount": 1
        }
      },
      {
        "id": "WorkflowRule:Account.Backfill_Region_On_Edit",
        "type": "WorkflowRule",
        "properties": {
          "active": false,
          "triggerType": "onAllChanges",
          "criteriaItemCount": 2
        }
      }
    ]
  }
}

3. Walk each rule's impact via sfi.get_impact on each id.
4. Respond:

Workflow rules on CustomObject:Account (extracted from workflows/Account.workflow-meta.xml):

WorkflowRule:Account.Notify_Sales_On_New_Tier1 — active: true, triggerType: onCreateOnly, criteriaItemCount: 1.

• Triggers on CustomObject:Account (triggersOn, declared).
• Criteria (verbatim, not evaluated): Account.Type equals 'Tier 1'. v1.3 lists what's configured; the per-record evaluation needs record data.
• Actions:
  • Alert action Email_Sales_Team (references, declared) → sendsEmail to EmailTemplate:Sales.WelcomeEmail (declared).
  • FieldUpdate action Set_Region_From_Country (references, declared) — sets CustomField:Account.Region__c via the formula IF(BillingCountry = "US", "Americas", "EMEA").

WorkflowRule:Account.Backfill_Region_On_Edit — active: false, triggerType: onAllChanges, criteriaItemCount: 2.

• Triggers on CustomObject:Account (triggersOn, declared).
• Criteria (verbatim, not evaluated): (Account.Region__c equals '' OR Account.BillingCountry notEqual '').
• Actions:
  • FieldUpdate action Set_Region_From_Country (references, declared) — shares the action target with the rule above.
• Inactive flag. This rule is extracted but active: false. Salesforce will not fire it; v1.3 still lists it because the metadata exists. Migration target or deletion candidate — decide per org policy.

v1.3 legacy-automation coverage: WorkflowRule (rules + alerts

• field updates + tasks + outbound messages, via the per- object Workflow container), ApprovalProcess (entry criteria
• step chain), AssignmentRule / AutoResponseRule / EscalationRule (per-object container with ruleEntry list), DuplicateRule + MatchingRule (the duplicate-prevention pair), EmailTemplate (text / html / visualforce / custom), Letterhead (theme reference). Rule → action targets resolve through declared edges; targets outside the extracted set surface as "target not in extracted set" rather than being silently dropped. Migration disclosure: Salesforce has superseded WorkflowRule and Process Builder with Flow for most use cases (Workflow Rules retire 2024+, Process Builder retired). v1.3 still extracts them honestly because real orgs still ship them in production, but when planning changes consider whether the rule should move to Flow before extending it.

Every rule is named with its canonical id. Every edge cites its confidence. The inactive rule appears with its active: false flag called out. The criteria text is surfaced verbatim, not evaluated. The migration disclosure is fixed-form and unskippable.

Boundary disclosure

v1.3's legacy-automation coverage has well-defined gaps. The fixed-form boundary disclosure (which the worked example above embeds verbatim) surfaces this list once per response. The list below documents what's behind each gap so Claude can answer follow-ups without paraphrasing.

• Workflow rule criteria evaluation. A WorkflowRule's <criteriaItems> or <formula> is extracted as a property string. v1.3 does not evaluate it against any record. "Does this rule fire for this Account?" is record-level. Direct the admin to Setup → Workflow Rules → {rule} → Test for per-record evaluation.

• Time-dependent workflow actions. Workflow rules carry <workflowTimeTriggers> that schedule actions for some offset (hours/days) after a criteria match. v1.3 surfaces the trigger count via the node's properties.timeTriggerCount and the declarative shape via properties.timeTriggers[] (each entry: timeLength, timeUnit, offsetFromField, actionCount) — all confidence declared. It does not model whether or when a trigger fires (the offsetFromField offset is measured from a record's field value, which is record-level), nor the per-trigger action chain or the scheduled-action queue. Direct the admin to Setup → Time-Based Workflow → View Pending Actions for the live queue.

• Per-rule immediate action counts. A WorkflowRule's IMMEDIATE <actions> are counted by <type> into properties.fieldUpdateCount, properties.outboundMessageCount, and properties.taskCreationCount (all confidence declared). These count the rule's consumed actions, NOT the top-level <fieldUpdates> / <outboundMessages> / <tasks> DEFINITION collections (a rule may consume only a subset of them), and NOT the time-trigger nested actions (those stay under timeTriggers[].actionCount). process_builder_migration_candidates reads these to score migration complexity.

• Approval process routing per step. ApprovalProcess approver evaluation depends on the approver type (userHierarchyField walks User.ManagerId per submitter, relatedUser reads a User lookup on the submitted record, queue and group are bundles). v1.3 stores the approver type and name as properties but does not resolve the approver per record. The skill walks the declared approver chain (the references edges); the runtime approver is record-level.

• Duplicate rule fuzzy matching. MatchingRule's <matchingMethod> (Exact, Fuzzy:Company Name, etc.) and <blankValueBehavior> are extracted as string properties. The actual fuzzy-match algorithm is opaque Salesforce platform code. v1.3 lists the field-and-method recipe; it cannot predict whether two specific records will collide.

• Duplicate rule <duplicateRuleFilter>. The boolean filter that scopes which records the rule applies to (e.g., "only active leads") is stored as a string property and not evaluated. Per-record applicability is out of scope.

• EmailTemplate body merge fields. EmailTemplate bodies contain {!Field_Reference} merge tokens. v1.3 stores the body as a string property but does not tokenize merge fields into per-field references edges (deferred to v1.4, parallel with LWC/VF template-reference work). If the admin asks "which fields does this template merge in?", surface the body verbatim and direct them to read it themselves; do not attempt to resolve {!Contact.FirstName} to CustomField:Contact.FirstName.

• Inactive rules. Workflow rules, approval processes, assignment / auto-response / escalation rules, and duplicate rules all carry an <active> / <isActive> / <ruleStatus> property. v1.3 extracts the flag and the rule itself regardless; always cite the active state when surfacing a rule, and flag inactive rules explicitly. An inactive rule isn't firing, but it's still part of the org's metadata surface area and counts for naming-collision and migration-target reasoning.

• OutboundMessage action targets. WorkflowRule actions of type OutboundMessage reference the OutboundMessage by name. The OutboundMessage metadata itself is not extracted as a node in v1.3 (deferred to v1.5 integration-topology). The references edge dangles by design — surface it as "target not in extracted set" and direct the admin to Setup → Outbound Messages.

• WorkflowTask action targets. Same treatment as outboundMessages — the rule's action references the task by name; the WorkflowTask metadata isn't a node in v1.3. Edge dangles, surfaced verbatim.

• OrgWideEmailAddress. Referenced by AutoResponseRule's <senderEmail> and WorkflowAlert's <senderAddress>. v1.3 stores the address as a string property; the OrgWideEmailAddress metadata is deferred to v1.5. Surface the address verbatim; do not attempt to resolve it to an organization-wide email node.

• EmailFolder hierarchy. Templates live under email/{Folder}/{Template}.email-meta.xml; the folder is captured in the canonical id (EmailTemplate:{Folder}. {Template}) but the EmailFolder itself is not a node. Folder-level access permissions are a Profile / PermissionSet concern outside v1.3.

• Process Builder. Process Builder is metadata-shaped as a Flow (<processType>Workflow</processType> in the Flow XML). v0.1's Flow extractor already covers it; v1.3 does not duplicate that coverage. If the admin asks "is this a Process Builder or a Workflow Rule?", point to the Flow: vs WorkflowRule: id prefix; the type is the answer.

• Inline criteria-field references. WorkflowRule, AssignmentRule, EscalationRule, and AutoResponseRule ship <criteriaItems> with <field> references. Where the COUNT lands differs per family, and getting this wrong reads as "no criteria":

  • WorkflowRule — criteriaItemCount is a NODE property (properties.criteriaItemCount), alongside formula and booleanFilter.
  • AssignmentRule — per-ruleEntry, on the EDGE: each outgoing references edge carries entryIndex, criteriaItemCount, hasFormula. There is no node-level count.
  • AutoResponseRule — per-ruleEntry, on the outgoing sendsEmail EDGE (entryIndex, criteriaItemCount, hasFormula). There is no node-level count.
  • EscalationRule — no criteriaItemCount at all, on the node or on any edge. Its node properties are active, ruleEntryCount, actionCount, conditions. Say the count is unavailable for escalation rules; do not report a missing count as zero criteria.

  None of the four emit per-field references edges from the rule to each criterion field, and none store the raw criteria field-and-value text as a node property — read the conditions mirror / ConditionalContext nodes for the expression instead.

• Workflow flow-trigger Apex (callsApex floor). When a WorkflowRule action is of type Apex, the rule node has a callsApex edge to the named ApexClass. The v0.1 Apex-source extractor handles the receiving class; v1.3 just extends the producer side.

• Migration to Flow. Workflow Rules and Process Builder retirement is in flight (Workflow 2024+, Process Builder already retired). v1.3 extracts both because real orgs ship them; the skill's migration disclosure recommends Flow as the modern replacement but does not auto-migrate.

Treat dangling edges as a flag for manual investigation — they're evidence that a target was deleted, renamed, or never extracted, and the admin needs the pointer to act on it. Treat inactive rules as still-part-of-the-metadata-surface — they don't fire, but they're a migration candidate or a cleanup candidate. Treat criteria text as documentation, never as an evaluator — v1.3 reads it verbatim and stops.

Anti-patterns

Example interactions

Happy path — "what workflow rules touch Account?"

See Reporting format above for the full transcript. Summary: parse to (type: 'WorkflowRule', parentId: 'CustomObject:Account'), enumerate via sfi.list_components, walk each rule's impact via sfi.get_impact, present as (active flag → triggers on → criteria text → actions → sendsEmail targets), append the fixed-form boundary disclosure with the migration paragraph.

Cross-reference — "which approval processes use this email template?"

User: "Which rules send the EmailTemplate:Finance.CreditApprovalNeeded email template?"

Claude's flow:

1. Parse → the question is a sendsEmail inversion. Target id is EmailTemplate:Finance.CreditApprovalNeeded (Folder.Template format).
2. Call sfi.get_edges with { nodeId: 'EmailTemplate:Finance.CreditApprovalNeeded', direction: 'in', edgeType: 'sendsEmail' }.
3. Receive (illustrative):

{
  "data": {
    "edges": [
      {
        "fromId": "ApprovalProcess:Account.Credit_Review",
        "toId": "EmailTemplate:Finance.CreditApprovalNeeded",
        "edgeType": "sendsEmail",
        "confidence": "declared",
        "properties": {
          "actionContext": "approvalSteps[1].notificationTemplate",
          "stepLabel": "Finance VP Approval"
        }
      }
    ]
  }
}

4. Respond:

One rule sends EmailTemplate:Finance.CreditApprovalNeeded:

• ApprovalProcess:Account.Credit_Review (sendsEmail, declared) — sent from approval step step_2_finance_vp (approvalSteps[1].notificationTemplate, label "Finance VP Approval"). The step's approver is Role:Finance_VP with Queue:Credit_Review_Queue as an alternate approver.

The process's other steps (step_1_sales_manager) and its top-level <emailTemplate> element point at different templates; this query was scoped to EmailTemplate:Finance.CreditApprovalNeeded only. If you want the full template inventory for this process, ask "which email templates does ApprovalProcess:Account.Credit_Review use?" and I'll walk the outgoing edges.

v1.3 legacy-automation coverage: [fixed-form boundary disclosure follows].

Migration recommendation — "should I migrate this workflow to Flow?"

User: "Should I migrate WorkflowRule:Account.Notify_Sales_On_New_Tier1 to Flow?"

Claude's flow:

1. Walk the impact chain first via sfi.get_impact on the rule's id. Surface the full target list (the triggersOn parent object, the references edges to the action targets, the sendsEmail edge to the template, any callsApex edges).
2. Then add the migration paragraph.
3. Respond:

Impact chain for WorkflowRule:Account.Notify_Sales_On_New_Tier1 (active: true, triggerType: onCreateOnly):

• Triggers on CustomObject:Account (triggersOn, declared).
• Criteria (verbatim): Account.Type equals 'Tier 1'.
• Actions:
  • Alert action Email_Sales_Team (references, declared) → sendsEmail to EmailTemplate:Sales.WelcomeEmail (declared). Recipient: Group:Sales_Group. Sender: CurrentUser.
  • FieldUpdate action Set_Region_From_Country (references, declared) — sets CustomField:Account.Region__c via the formula IF(BillingCountry = "US", "Americas", "EMEA").

Migration considerations:

Salesforce has superseded WorkflowRule and Process Builder with Flow for most use cases (Workflow Rules retire 2024+, Process Builder retired). v1.3 still extracts WorkflowRules honestly because real orgs still ship them in production — but when planning changes, consider whether the rule should move to Flow before extending it. Migration considerations grounded in the impact chain above:

• The criteria predicate Account.Type equals 'Tier 1' translates to a Record-Triggered Flow with a start condition $Record.Type = 'Tier 1' and the On Create trigger type matching onCreateOnly.
• The Alert action's EmailTemplate:Sales.WelcomeEmail target must be reproduced in the Flow via a **

…(truncated)