# Business Validation Checklist

> Business-led acceptance criteria for publishing a reusable TiDB baseline branch and validating downstream test branches.

## Purpose

This checklist provides structured validation for business operators to verify that the baseline-loaded data meets expectations before downstream teams use TiDB branches for broader testing. It is NOT just "click around and see if it feels right" — it defines specific, repeatable acceptance criteria.

---

## Validation Scope

```
Baseline Validation Scope: P0 Core Business
├── Account (3,307 records)
├── Contact (7,067 records)
├── Lead (370,772 records)
├── Opportunity (3,568 records)
└── User / minimal assignment data

Out of Scope for Initial Validation:
├── Historical activities (Task, Event) — P2
├── Large volume data (CampaignMember) — P2
└── Full access-model parity / full permission-definition copy
```

This checklist is for the canonical baseline branch first. Once the baseline passes, downstream test branches can focus on feature / flow validation instead of re-proving the entire import from scratch.

---

## Validation Dimensions

### Dimension 1: Object/Field Semantic Correctness

Verify that the meaning of migrated data is preserved.

**Account**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Account names visible | All 3,307 account names | | ☐ |
| Account types match source | Customer/Partner/Competitor distribution | | ☐ |
| Industry values preserved | Industry picklist values | | ☐ |
| Owner assignments correct | OwnerId points to valid User | | ☐ |
| Billing address complete | Street/City/State/PostalCode/Country | | ☐ |

**Contact**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Contact names visible | All 7,067 contact names | | ☐ |
| Account association correct | Contact.AccountId -> Account.Id | | ☐ |
| Email addresses valid | All contacts have email | | ☐ |
| Department values preserved | Department picklist distribution | | ☐ |

**Lead**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Lead names visible | All 370,772 lead names | | ☐ |
| Lead status distribution | Source status percentages | | ☐ |
| Lead source values preserved | LeadSource picklist values | | ☐ |
| Company field populated | All leads have Company | | ☐ |

**Opportunity**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Opportunity names visible | All 3,568 opportunity names | | ☐ |
| Stage distribution correct | Source stage percentages | | ☐ |
| Amount values preserved | Currency precision maintained | | ☐ |
| Close date range correct | Reasonable date range | | ☐ |
| Account association correct | Opportunity.AccountId -> Account | | ☐ |

### Dimension 2: Page/Layout Rendering

Verify that users can see migrated data in the UI correctly.

**Account Page**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Account name displays | Name field visible in header | | ☐ |
| Related lists render | Contacts, Opportunities, Cases | | ☐ |
| Custom fields display | L2 custom fields visible | | ☐ |
| Page layout sections | Standard sections present | | ☐ |

**Contact Page**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Contact name displays | Full name in header | | ☐ |
| Account link works | Click Account -> Navigate | | ☐ |
| Activity timeline | Tasks/Events related to contact | | ☐ |

**Lead Page**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Lead header correct | Name + Company visible | | ☐ |
| Status field editable | Can change Lead Status | | ☐ |
| Convert button present | Lead conversion available | | ☐ |

**Opportunity Page**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Stage field editable | Can change StageName | | ☐ |
| Amount displays correctly | Currency formatted | | ☐ |
| Close date editable | Can update CloseDate | | ☐ |
| Account link works | Navigate to Account | | ☐ |
| Products related list | If OpportunityLineItems exist | | ☐ |

### Dimension 3: User Access Control

Verify that users can access what they should and cannot access what they shouldn't.

Important:

- Validate access against the intended target pack/config model.
- Do not assume source-side permission-definition parity is required for baseline acceptance.
- Focus on whether the scoped test users can execute the required validation workflows.

**Profile-Based Access**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Admin can see all accounts | Full read access | | ☐ |
| Sales rep sees assigned accounts | Based on OwnerId | | ☐ |
| Read-only user cannot edit | Create/Edit disabled | | ☐ |
| Field-level security works | Certain fields hidden for specific profiles | | ☐ |

**Record Type Access**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Users see correct record types | RecordType assignment respected | | ☐ |
| Record type page layouts correct | Different layouts per RT | | ☐ |

**Sharing Model**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Private sharing: users see own records | Owner-based visibility | | ☐ |
| Public read: all see all | No Owner restriction | | ☐ |

### Dimension 4: In-Scope Process Correctness

Verify that business processes work with migrated data.

**Lead Conversion**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Convert button creates Account | New Account from Lead.Company | | ☐ |
| Convert creates Contact | New Contact from Lead name | | ☐ |
| Convert creates Opportunity | Optional, if lead has opportunity | | ☐ |
| Convert updates Lead status | Lead marked as Converted | | ☐ |

**Opportunity Stage Flow**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Stage validation fires | Opp_Launch_Stage_Validation flow | | ☐ |
| Stage update triggers | Stage-dependent flow actions | | ☐ |

**Account Status Flow**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Account status flow works | Account_status_Flow triggers | | ☐ |
| First Order Start Date updates | Account.First_Order_Start_Date__c | | ☐ |

**Task Creation**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Quick create task works | Std_CreateTaskActivity flow | | ☐ |
| Task assignment correct | Owner set properly | | ☐ |

### Dimension 5: Relationship Integrity

Verify that lookup relationships point to correct records.

**Cross-Object References**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| Contact.AccountId valid | Points to existing Account | | ☐ |
| Opportunity.AccountId valid | Points to existing Account | | ☐ |
| Opportunity.CampaignId valid | Points to existing Campaign | | ☐ |
| Account.OwnerId valid | Points to existing User | | ☐ |
| Opportunity.OwnerId valid | Points to existing User | | ☐ |
| Lead.OwnerId valid | Points to existing User | | ☐ |

**Orphan Detection**

| Check | Expected | Actual | Pass |
|-------|----------|--------|------|
| No orphaned Contacts | All Contact.AccountId -> Account | | ☐ |
| No orphaned Opportunities | All Opp.AccountId -> Account | | ☐ |
| No orphaned Tasks | All Task.OwnerId -> User | | ☐ |

**Query to detect orphans:**

```sql
-- Find Contacts without valid Account
SELECT c.Id, c.Name, c.AccountId
FROM contact c
LEFT JOIN account a ON c.AccountId = a.Id
WHERE c.AccountId IS NOT NULL AND a.Id IS NULL;

-- Find Opportunities without valid Account
SELECT o.Id, o.Name, o.AccountId
FROM opportunity o
LEFT JOIN account a ON o.AccountId = a.Id
WHERE o.AccountId IS NOT NULL AND a.Id IS NULL;
```

---

## Validation Reporting

Use this reporting section to decide whether the imported dataset is ready to become the canonical baseline branch.

### Record Count Validation

| Object | Source Count | Target Count | Match | % Diff |
|--------|-------------|---------------|-------|--------|
| Account | 3,307 | | | |
| Contact | 7,067 | | | |
| Lead | 370,772 | | | |
| Opportunity | 3,568 | | | |
| User | 319 | | | |

### Data Quality Validation

| Metric | Account | Contact | Lead | Opportunity |
|--------|---------|---------|------|-------------|
| Required field null rate | | | | |
| Email format validity | | | | |
| Date range validity | | | | |
| Picklist value coverage | | | | |

### Relationship Validation

| Relationship | Total | Valid | Orphan | Orphan % |
|--------------|-------|-------|--------|----------|
| Contact -> Account | | | | |
| Opportunity -> Account | | | | |
| Opportunity -> Campaign | | | | |
| Task -> Owner | | | | |

---

## Business Operator Sign-off

For each validation dimension, business operator confirms:

```
Dimension 1: Object/Field Semantic Correctness
  Verifier: [Name]
  Date: YYYY-MM-DD
  Result: PASS / FAIL
  Notes: [Any issues observed]

Dimension 2: Page/Layout Rendering
  Verifier: [Name]
  Date: YYYY-MM-DD
  Result: PASS / FAIL
  Notes: [Any issues observed]

Dimension 3: User Access Control
  Verifier: [Name]
  Date: YYYY-MM-DD
  Result: PASS / FAIL
  Notes: [Any issues observed]

Dimension 4: In-Scope Process Correctness
  Verifier: [Name]
  Date: YYYY-MM-DD
  Result: PASS / FAIL
  Notes: [Any issues observed]

Dimension 5: Relationship Integrity
  Verifier: [Name]
  Date: YYYY-MM-DD
  Result: PASS / FAIL
  Notes: [Any issues observed]
```

---

## Final Acceptance

```
Overall Baseline Result: READY FOR BRANCHING / NEEDS REMEDIATION / REBUILD BASELINE

Business Owner Sign-off:
  Name:
  Date:
  Signature:

Technical Sign-off:
  Name:
  Date:
  Signature:
```

If the result is `READY FOR BRANCHING`, downstream teams may create TiDB test branches from the validated baseline.

If the result is `REBUILD BASELINE`, do not patch the dirty test branch in place. Reset or recreate from the canonical baseline after fixing pack, schema, or loader issues.

---

## Related Documents

- SALESFORCE_DATA_MIGRATION.md — Migration overview
- SCHEMA_COMPATIBILITY.md — Pre-migration schema check
- FIELD_MAPPING.md — Field correspondence
- ROLLBACK_PLAN.md — Recovery procedures if validation fails