---
name: moltsets-attio-signup-expansion
description: Expand thin Attio form fills and product signups into full person records with MoltSets, so lifecycle workflows have real data from message one.
---

# Attio Signup Expansion

## Triggers

- "Enrich new signups in Attio into full person records before the lifecycle workflow runs"
- "Expand this form-fill person with name, title, LinkedIn, and firmographics"

## What this skill does

Expands a thin new Attio person record into a full record at the point of creation. A form fill or product signup often arrives as just an email, or a name and a work domain. This skill takes whatever is present and fills in the name, title, LinkedIn URL, company, and firmographics through MoltSets, so lifecycle segmentation and onboarding workflows have complete data before the first message goes out.

## Chain

```
New Attio person record (form fill / signup)
  to attio/get-record                   (read what exists: email, or name + domain)
  to MoltSets:
      reverse_email_lookup              (email -> name, title, company, LinkedIn)
      search_business_profile_by_name   (name + domain fallback -> title + firmographics)
  to fill gaps: name, title, LinkedIn, company, firmographics
  to attio/update-record                (write enriched fields for lifecycle workflows)
```

## Inputs

- **Trigger scope** - which new records to enrich (a specific form, a signup source, or all newly created people)
- **Starting data** - what the record arrives with (email only, or name plus company domain)
- **Fields to fill** - name, title, LinkedIn, company, industry, employee count, and any scoring inputs
- **Guardrails** - skip free-mail domains, or flag them for a lighter enrichment path
- **Acceptable risk scores** - which A-F deliverability grades to keep (recommended: A, B, C and F; D excluded)

## Risk scores - confirm before enriching

Every email MoltSets returns carries a deliverability risk score - a grade from A to F. Ask which grades to keep before running anything:

> "MoltSets grades email deliverability risk from A (best) to F (no data). Which grades should I keep? I'd recommend **A, B, C and F** - and dropping **D**, since D is a confirmed bounce, complaint or spam trap."

| Grade | Meaning | Best practice |
| --- | --- | --- |
| A | Strongest engagement signal available | Safe to send immediately |
| B | Solid | Fine in regular sends; on a new or warming domain, send a smaller batch before scaling |
| C | Deliverability can't be confirmed | Segment separately from A/B, warm at low volume, watch engagement, suppress non-responders after 1-2 attempts |
| D | Confirmed bounce, complaint or spam trap | Never send - fastest way to trip spam traps and damage sender reputation for the whole list |
| F | No data - unknown risk, not "safe" | Re-verify before sending, or treat like C |

Use whatever set the user confirms. Treat the grade as a filter, not a guarantee - it lowers risk, it doesn't remove it. Pair it with the user's own sending domain reputation and list hygiene.

## How it works

1. Reads the newly created person record and checks which attributes are present
2. When an email is on the record, runs `reverse_email_lookup` to resolve name, title, company, and LinkedIn
3. When only a name and company domain are present, runs `search_business_profile_by_name` to return title and firmographics
4. Fills the gaps on the record without overwriting anything the person supplied themselves
5. Writes the enriched fields back so lifecycle workflows and segmentation can branch on real data immediately

Before any write-back, every found address is checked against the accepted grade set. Out-of-range grades are reported in the table with their true score and skipped - never written to the CRM.

## Output

| Email | Risk | Name | Title | Company | Industry | LinkedIn | Fields Filled | Action |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |

Show the risk score on every row that has an email, including grades outside the accepted set - flag those in `Action` (e.g. "held - grade D") rather than dropping them silently. Only emails inside the accepted set are written back to the CRM.

```
New records processed:   X
Enriched to full record: X/N (XX%)
Free-mail flagged:       X
MoltSets tokens used:    X

Email risk scores:
  A: X   B: X   C: X   D: X   F: X
  kept (accepted grades):  X
  filtered (excluded):     X
```

## Tips

- Requires the Attio MCP (mcp.attio.com) and the MoltSets MCP connected in the same client
- Never overwrite a value the person entered themselves; only fill blanks, so self-reported data stays intact
- Free-mail domains (gmail.com, outlook.com) rarely resolve to firmographics, so route those to a lighter path
- Enriching at creation gives your first lifecycle email something to personalise on, which lifts early engagement
- Attio's automations can trigger this skill directly off a "record created" event on the People object, so the enrichment can run without a separate scheduled job
- For high signup volume, batch enrichment on a short interval rather than one call per record to manage token flow