Salesforce Administration,
Rebuilt with AI
I administer a production Salesforce org and built an agentic AI system on Claude Code that automates the support ticket lifecycle. Leadership adopted it department-wide and asked me to train the admin and developer teams.
Where I've Done the Work
Salesforce and Pardot are not tools I picked up for a portfolio. They have been my day job for a decade, from freelance marketing automation to administering a production org for a national nonprofit.
Salesforce Administrator
Dec 2024 to Present- Administer the production Salesforce org: user provisioning, role and profile configuration, permission sets, data quality audits, custom reports, and Flow troubleshooting.
- Designed and built the agentic AI workflow featured below. After it proved out across 98+ tickets, leadership adopted it department-wide and selected me to lead adoption.
- Onboarded the Salesforce admin team onto Claude Code and VS Code, and run a weekly hands-on training session for the admin and developer teams (12 trained so far).
- Resolve cross-platform Salesforce to Pardot issues (sync errors, form handlers, segmentation) that would otherwise route to engineering.
Senior Pardot Automation Specialist
Jun 2022 to Dec 2024- Developed and managed end-to-end marketing campaigns: landing pages, email sends, and multi-step nurture programs with audience segmentation that improved qualified-lead quality for the handoff to sales.
- Streamlined complex Pardot automation and scoring models to sharpen lead qualification; reworked inherited flows to remove stale rules and fix silent sync failures.
- Delivered campaign performance insights via Salesforce reports and dashboards that guided ongoing nurture strategy.
Freelance Marketing Automation Specialist
2016 to Present- Built and optimized automated marketing campaigns across Pardot (since 2016), HubSpot, and Mailchimp for client businesses.
- Designed HTML/CSS landing pages, ran A/B tests, and managed PPC campaigns; delivered analytics via Google Analytics, Moz, and SEMRush.
Agentic AI Workflow for Salesforce
An agentic AI system I designed from scratch that turns Claude Code into a consistent partner for Salesforce support. Every ticket runs the same five-phase lifecycle, from discovery to a validated root cause, with a governance layer most AI tools skip. After it proved out, leadership adopted it department-wide.
Measured across 98+ tickets. Consistent artifacts and an audit-ready paper trail on every one.
How a Ticket Flows Through the System
This is the actual working order, from the moment a ticket lands to the moment its learnings feed the next one.
Discovery
Investigate org metadata: objects, flows, triggers, fields. Confirmed evidence stays separate from speculation.
Diagnosis
Pin down root cause and produce step-by-step fix notes, for me to run or as a clean dev handoff.
Validate
Check every expected behavior against debug logs. Pass or fail per step, with evidence.
Retro
Debrief the closed ticket against its own evidence. What assumptions were wrong? What would make the next one faster?
Knowledge Capture
Create or update reference docs and runbooks, and fine-tune the skills themselves.
The Five-Phase Ticket Lifecycle
Support work has a repeating shape: dig through Setup, cross-reference metadata by hand, write up findings, hand off, then start from scratch on the next ticket. The workflow replaces that with a fixed pipeline. Every ticket, simple or complex, produces the same artifacts and leaves the same paper trail.
Discovery writes findings with confirmed evidence clearly separated from speculation. Diagnose pins down root cause and produces implementation-ready notes. Validate checks each expected behavior against debug logs, pass or fail per step. The AI never pushes changes to the org. That action is always human.
AI Governance: The Confidence Check
The dangerous failure mode in AI-assisted support is not a wrong answer that sounds wrong. It is a plausible root cause that sounds right, gets reported to a stakeholder, and turns out to be an inference dressed up as a fact.
So I built a skill that breaks every finding into its component claims, grades the actual evidence behind each one, and caps how confident the AI is allowed to sound based on what kind of evidence it really has.
Overall confidence is the lowest sub-claim score, not an average: a root cause with airtight mechanism evidence but a 40% timing claim is a 40% root cause. Above 90%, it ships as a finding. Between 70 and 89, it ships with explicit caveats. Below 70, it is a hypothesis, and nobody acts on it until the validation runs.
| Evidence behind a claim | Cap |
|---|---|
| Live query or fresh screenshot | 98% |
| Metadata snapshot or saved result | 92% |
| Pattern match from a prior ticket | 70% |
| Correlation, no controlled test | 65% |
| No cited evidence at all | 60% |
| "Likely" with no specific evidence | 45% |
Metadata-Verified SOQL
Describe what you want in plain English; get back a query where every field was verified against a pre-built metadata index before it was used. The skill will never guess a custom field name: if a field is not in the index, it says so instead of inventing one.
On a real request for stale-stage Opportunities, it surfaced a custom field tracking exactly when Stage last changed, instead of building an OpportunityHistory workaround by hand. PII-flagged fields are stripped from the SELECT clause automatically.
Automated PII Redaction
A Python pipeline runs 13 targeted redaction passes over any file before it can go into an AI tool: names, emails, phones, SSNs, org names, domains, and URL tokens. Record IDs, timestamps, and log structure survive, so the scrubbed file is still fully usable for investigation.
The same value always gets the same tag: the email appears twice, and both times it becomes REDACTED_EMAIL_1, so one person stays traceable through an entire log. Every run is audit-logged, and the raw file is deleted in the same step.
A Knowledge Base That Compounds
Ticket folders age out after 30 days. Two skills capture what would otherwise vanish: reference docs explain how a system works end to end, runbooks capture step-by-step procedures with verification and rollback. Recurring issues take minutes to look up instead of hours to re-investigate, and the knowledge survives turnover.
Session Continuity
Tickets pause for weeks waiting on vendors or devs. A handoff skill saves structured state; a pickup skill restores it with a six-line briefing:
Re-oriented in under a minute, with no risk of re-running a concluded investigation.
The System Improves Itself
When a ticket closes, a retrospective skill reads the full investigation record and extracts signals before asking a single question: which assumptions were never verified, whether the components touched were known territory, how many hypothesis revisions it took to reach root cause. Each learning routes to the right home: a runbook, a reference doc, or a standing-rule change.
The part I am proudest of: if a skill underperformed on the ticket, a second phase walks through that skill's own instructions section by section and edits them on the spot, before the next ticket hits the same gap. The system gets measurably better at the job every week without manual maintenance.
Live SFDX Environment and Risk-Tiered Command Safety
Once the snapshot-based workflow was solid, I stood up a fully live Salesforce DX environment (VS Code + Salesforce CLI) against a pre-production sandbox, built the way a production CI pipeline should look: ESLint and Prettier enforced on every commit via Husky, Jest unit tests running against exactly the LWC components that changed, and a two-branch Git strategy that keeps a 53-metadata-type investigation snapshot from ever contaminating a clean, reviewable ticket branch.
The bigger design decision was trust. Every CLI operation is classified into three risk tiers, enforced both in the written rules the AI follows and in hard hooks that block the command outright:
| Tier | Operations | Policy |
|---|---|---|
| Always allowed | Retrieve, query, lint, test | Cannot hurt anything; runs freely |
| Approval required | Deploy, push, anonymous Apex | Explicit human approval, every time |
| Hard blocked | Bulk data import or delete | Never runs via CLI; stays manual in the UI, permanently |
I planned this as a team rollout, not a personal setup: a private-repo distribution model so the whole support team pulls skill and guardrail updates via git, plus the full documentation set. Today I run a weekly hands-on training session teaching the workflow to the admin and developer teams.
What It Replaced
| Before | With the workflow |
|---|---|
| Start every ticket from scratch | Scaffold gives a clean, consistent starting point |
| Investigation lived in one admin's head | Investigation lives in versioned docs, with evidence |
| Root cause was "I think it's this" | Root cause is backed by metadata and logs |
| Long tickets got dropped or re-investigated | Handoffs preserve state across weeks |
| Hard-won org knowledge got lost | 20 runbooks and 34 reference docs keep it |
| Each admin solved problems their own way | Repeatable skills produce consistent output |