Variable chips & template variables

Every vishing scenario is a template with placeholders in it, {{first_name}}, {{agent_name}}, {{company}}, {{policy_reference}}, and so on. Callstrike classifies each placeholder by where its value comes from and renders it as an inline, colour-coded chip right inside the script, so an operator reads a natural, filled-in call opening instead of raw {{tokens}}, and can tell at a glance what is fixed versus what they control.

Three sources exist:

• Target: filled from the person being called (the Training Target record), e.g. first_name, department.
• Attacker identity: the impersonator's fabricated identity, e.g. agent_name, never a real person.
• Operator: a pretext value the operator supplies per campaign, e.g. company, policy_reference.

Target variables further split into two tiers: guaranteed (first_name, last_name, email, phone, present on every target regardless of how it was added) and directory (department, job_title, manager_name, manager_email, office_location, employee_number, supplied only when a directory connection maps them, which is commonly absent).

Prerequisites

• A scenario/template with declared variables (built-in catalog templates or a custom template built with the AI generator or the guided editor).
• To open a campaign's scenario drawer: campaign-wizard access (Step 1, scenario selection).
• To edit a custom template's Variables section: the custom-template-builder permission for your workspace.
• Directory-sourced variables (department, job title, manager, office location, employee number) only populate when directory sync is configured and the provider/connection supplies that attribute, see SSO & Directory Sync. Manual and CSV-imported targets never have them.

How to use it

Reading and editing chips in the campaign wizard

1. In the campaign wizard, open a scenario card in Step 1. The Attack Anatomy timeline renders with every placeholder as a chip instead of a raw token.
2. Guaranteed-target chips (the victim's name) render locked and grey, pre-filled with your own first name as the stand-in victim, with a lock glyph. Hovering explains it fills automatically from each real target at call time. Clicking the locked first-name chip toggles between first-name and full-name greetings.
3. Attacker-identity, operator, and directory-target chips render editable (light blue = suggested, teal/green = you've edited it). Click one to open an inline editor with the current value pre-filled and focused.
4. Type a value and click Save (or press Enter). Every occurrence of that variable across the script, and in the recap strip below it, updates together and the chip switches to the edited state.
5. For a directory-target variable, the editor also shows an "Always use my value (ignore directory)" switch. Turn it on to make your value authoritative for every target in this campaign, regardless of what the directory holds for each person.
6. Click the ✨ button in the editor to generate a value. An instant, locally-picked sample fills the field immediately; a moment later a tailored, AI-generated value replaces it if one comes back in time. A slow or failed generate leaves the instant sample in place; it never blocks typing or saving.
7. Below the script, "Customize the details" lists every editable variable as the same kind of chip (name → current value), a compact recap, not a separate form. Editing a chip there behaves identically to editing it in the script. Guaranteed-target variables never appear in the recap.
8. You can proceed to launch without opening any chip, unedited chips carry their suggested value, which is what the campaign uses.

Marking variable sources in the custom-template editor

1. Open a custom template's editor and scroll to the Variables section.
2. Rows whose variable resolves to target show a tier badge, "Always from target" (guaranteed) or "From directory": with a tooltip explaining the mechanism, and their name field is locked (not renamable, not deletable), so the binding to a target attribute can't be broken by a rename.
3. Attacker-identity and operator rows remain fully editable and deletable, exactly as before this feature.

Configuration & options

Option	Where	What it does	Default
source	Template variable (target | attacker_identity | operator)	Explicit classification stored on the variable; when absent, inferred from the variable's name via a canonical name mapping.	Inferred if not set
Guaranteed vs. directory tier	Derived, target variables only	Guaranteed (first_name/last_name/email/phone) always injects the target's real value and is never operator-settable. Directory (everything else target-shaped) is optional and overridable.	n/a
Chip value	Campaign variable	The operator's current value for a variable in this campaign; stored additively alongside the campaign (no template or schema change).	Instant suggestion until edited
Override (directory variables only)	Campaign variable	When on, the operator's value is used for every target in the campaign, ignoring that target's directory attribute. When off (default), the target's attribute is used when present, else the operator's value as fallback, else blank.	Off (fallback)
Full-name toggle	Locked first_name chip	Click to greet with "First Last" instead of first name only (uses the target's real last name; ignored if the target has none).	First name only
Generate (✨)	Chip editor	Requests an AI-tailored sample value for the variable; always backed by an instant local sample so there's no blank wait.	n/a

Gotchas & limitations

• Directory attributes are commonly absent, by design, not by bug. Beyond first/last name, target attributes come from optional directory attributes that must be mapped per connection and are provider-dependent (for example, Google Workspace supplies no manager or organization attribute). A blank directory-target chip for a manual/CSV workspace, or for an entire provider, is expected behavior, the fallback path (target value → operator value → blank) is the default case, not an edge case.
• company is classified operator, not target. The Training Target record has no organization/company column to resolve it from; this is unrelated to whether directory sync could theoretically supply one. In preview and chips it shows the operator's own organisation name (or "your organisation" if unavailable).
• Guaranteed variables can never be overridden. first_name/last_name/ email/phone always inject the real target's value; there is no operator override for them, by design (they're identity fields, not pretext).
• An unrecognised variable name defaults to operator, never to a locked state, so a renamed or AI-generated variable the classifier can't map is always safely editable rather than silently mis-locked.
• Editing a chip only changes the current campaign. It never modifies the stored scenario template, the AI-generated template it came from, or any other campaign; the value is stored on the campaign itself.
• An edited value cleared back to empty reverts to the suggested state, it doesn't leave a blank gap in the script.
• The scenario-card preview substitution is a separate, isolated mechanism from these chips; it only affects the cosmetic Step 1 card text (fabricated values, deterministic per template) and never reads or writes real campaign values. Don't confuse a card's preview line with what a chip currently holds.
• Generate is best-effort. If the AI-tailored call is slow or fails, the operator still has the instant local sample and can save or keep typing, generation is never a blocking dependency for editing or launching.

Best practices

• Leave guaranteed-target variables alone. There's nothing to set; they're locked because the platform must inject the real target's identity.
• For directory-target variables, prefer the default fallback behavior (your value only fills gaps) unless you specifically want to override every target's real directory data with one campaign-wide value.
• You don't have to open every chip before launching, suggested values are launchable defaults. Review them, but don't treat filling every chip as a gate.
• Use ✨ generate when you're unsure what a good sample looks like for an unfamiliar field (an identifier, a reference number) rather than guessing a format.

Troubleshooting / FAQ

Why is a variable I expected to be editable showing as a locked grey chip? It resolved to a guaranteed-target source (its name matches first_name, last_name, email, or phone, or its declared source says so). Guaranteed variables always carry the real target's value and are never operator-set. If that's wrong for your use case, name the variable something that doesn't match the guaranteed set and classify/declare it as operator in a custom template.

Why is a directory-target chip (e.g. department) blank for some targets and filled for others? That's expected: the target's directory attribute is used when present, and falls back to your operator value (or blank) when it isn't. Absence is the norm for workspaces without directory sync, or for attributes a provider doesn't support (e.g. Google Workspace has no manager attribute).

Why did the ✨ generate button just show a sample instantly instead of an AI-written one? That's the instant local suggestion shown immediately so there's no blank wait; the tailored AI value replaces it a moment later if it returns in time. If the request fails or is slow, the instant sample stays and nothing blocks you from saving or typing your own value.

Does editing a chip change the template for other campaigns? No, a chip's value and override choice are stored per campaign. The underlying scenario template, and every other campaign using it, are unaffected.

Related

• Vishing Scenarios overview
• Create and launch a campaign
• Target Audience
• SSO & Directory Sync