ABC Contacts Module — Testing Playbook

The Rule: A company can only be deleted if it has NO invoices, NO event registrations, NO directory proofs, NO individuals with employment history. If any of these exist, deletion is blocked with specific error message naming what's preventing it.

• Attempt to delete company with active individuals: Fails (individuals must be deleted first, but only if no history)
• Attempt to delete company with invoices: Fails with message "Cannot delete: X invoices exist"
• Attempt to delete company with event registrations: Fails with message "Cannot delete: X registrations exist"
• Delete all dependent records, then delete company: Succeeds
• Portal users cannot delete companies (staff-only operation)

The Rule: An individual can only be deleted if they have NO employment history (i.e., have never been moved to another company). If history exists, deletion is blocked. Inactivity does NOT prevent deletion — only history does.

• Delete new individual at single company: Succeeds
• Delete individual who has been moved to another company: Fails with message "Cannot delete: Employment history exists"
• Delete inactive individual with no history: Succeeds
• Delete individual with multiple contact types at same company: Succeeds (if no history)
• Portal users cannot delete individuals (staff-only operation)

The Rule: Cannot have two ACTIVE individuals with the same email at the same company. Can have same email across different companies. Can have same email if one is inactive. Can have inactive + active only if explicitly different emails per active rule.

• Add individual john@example.com to Company A: Succeeds
• Try to add another active individual john@example.com to Company A: Fails with "Email already exists in this company"
• Add individual john@example.com to Company B: Succeeds (different company)
• Add inactive individual john@example.com to Company A (where active john@example.com exists): Succeeds (inactive exception)
• Change active individual email from john@example.com to jane@example.com, then try to add john@example.com as new individual: Succeeds
• Portal user edit of individual email triggers same check

The Rule: Only one address per record can be marked "Is Primary". If you try to set a second address as primary, system should either auto-flip the old one to non-primary or reject with error. Behavior is system-configurable.

• Add primary address to individual: Succeeds, marked Primary
• Add second address and mark as primary: Either auto-flips first to non-primary, or rejects with "Only one primary address allowed"
• Delete the primary address when backups exist: Succeeds, one of remaining addresses becomes new primary or stays non-primary
• Delete primary address when it's the only address: Succeeds, individual now has no address

The Rule: When creating a company without specifying Type, system applies defaults in this order: (1) User's personal default setting, (2) Chapter's default setting, (3) National default setting. If user has never set a preference, their default is blank and chapter default is used.

• User with personal Company Type default creates company without specifying type: Personal default applied
• User with NO personal default, chapter has default, creates company: Chapter default applied
• User with NO personal default, chapter has NO default, creates company: National default applied
• User can override any default by explicitly choosing type during creation
• Changing user's personal default does NOT affect already-created companies

The Rule: Portal permission level (MPA, Registration, Limited) determines which fields can be viewed/edited.

• Member Portal Admin (MPA): Can view and edit all company data, add/remove individuals, manage contact types, edit trade codes, market segments, business designations. Cannot create new companies or change company status.
• Portal Individual with Registration: Can view and edit company profile and own individual record. Cannot add/remove other individuals or change contact types or trade codes.
• Portal Individual with Limited: Can view company profile and own individual record. Read-only, cannot edit anything.
• Portal user trying to access restricted field: Field appears read-only or disappears from form
• Portal user cannot view sensitive audit reports or compliance data

The Rule: Lookup tables have different governance models. National-only values cannot be changed by chapters. National-approved values can be requested by chapters via approval workflow. Chapter-managed values are fully controlled by each chapter.

• National-only: CSI code list, some business designations. Chapters see these values but cannot add, edit, or delete.
• National-approved: Trade code additions, new business designations. Chapter can request, National admin approves or rejects. Once approved, becomes available in chapter.
• Chapter-managed: Individual Type, some business designations. Chapter fully controls values. Can add, edit, delete. No national override.
• Deletion of lookup value: Value is cleared from all records using it (records are not deleted, value is unlinked)
• Chapter cannot see National's pending requests from other chapters

The Rule: Directory Proof max controls how many CSI codes and NAICS codes a company can have. Set per chapter, default typically 3-5 per type. Exceeding limit triggers validation error on add, or audit failure when running audits. Reducing limit below current count triggers audit failure but does not auto-delete codes.

• Chapter sets directory proof max CSI = 3
• Company has 2 CSI codes: Allowed
• Try to add 3rd CSI code: Succeeds
• Try to add 4th CSI code: Fails with "Directory Proof limit exceeded (max 3)"
• Chapter reduces max to 2. Company still has 3: Audit failure, not auto-delete
• Staff or MPA must manually remove codes to bring back into compliance

The Rule: Market Classifications are split into groups. Within each group, percentages must total 100% if market classification is used. Groups: (1) Public/Private/Federal, (2) Commercial/Industrial/Residential. If company has NO market classification, both groups are empty (allowed). If company HAS market classification, both groups must total 100%.

• Company with no market classification: Allowed (empty)
• Company with Public=50%, Private=40%, Federal=10%: Allowed (totals 100%)
• Try to set Public=50%, Private=40%: Fails (Federal is missing, doesn't total 100%)
• Set Commercial=60%, Industrial=30%, Residential=10%: Allowed (totals 100%)
• Try to set Commercial=60%, Industrial=30%: Fails (Residential missing)
• Audit will flag non-compliant records (percentages != 100%)

The Rule: When creating an individual, "Informal Name" field auto-populates with First Name value. User can manually override it. Once set manually, it stays as manually edited and does NOT auto-update if First Name changes later.

• Create individual John Smith: Informal Name auto-fills with "John"
• User manually changes to "Johnny": Informal Name is now "Johnny"
• Later edit, change First Name to "Jonathan": Informal Name stays "Johnny" (does not auto-update)
• Portal user can manually edit Informal Name if they have edit permission

The Rule: If a Contact Type is flagged as "Member Portal Admin" and it is assigned to an Individual at a Company where portal is ENABLED, a portal invitation email is automatically sent to that individual. If portal is disabled, no invite is sent. If portal is later enabled, all existing MPAs get invited.

• Company portal is OFF, assign "MPA" contact type to individual: No invite sent
• Company portal is ON, assign "MPA" contact type to individual: Invite sent immediately
• Company portal is OFF, then enable it: All existing MPA contacts get invited
• Individual already has portal account at another company, gets MPA assigned here: Receives invite, same account can now manage both companies (if system supports multi-company access)
• Disable portal: All active sessions end, invites become invalid

The Rule: Toggling the portal on or off for a company requires explicit confirmation prompt. Prompt should explain implications (invites sent if turning ON, users logged out if turning OFF). User must confirm before action executes.

• Portal is OFF, click toggle to ON: Confirmation prompt appears ("Enable portal? MPAs will receive invites.")
• User confirms: Portal enabled, invites sent, page updates
• User cancels: Portal stays OFF, no change
• Portal is ON, click toggle to OFF: Confirmation prompt appears ("Disable portal? All users will be logged out.")
• User confirms: Portal disabled, sessions ended, invites invalidated

The Rule: Contact Audit supports 31 distinct data quality checks. Each criterion is independently selectable. All criteria must be correctly implemented and accurate.

• Missing company email
• Missing individual email
• Duplicate individuals in same company (same first+last name)
• Invalid trade code (code not in national or chapter lookup)
• Invalid business designation
• Market classifications do not total 100% (if populated)
• Company narrative exceeds character limit
• Address missing city/state/zip
• Individual address missing phone
• No primary address (if address required)
• Multiple primary addresses
• Individual with no contact type
• Individual inactive with no end date
• Individual email inactive but in use elsewhere
• Directory proof exceeded (too many trade codes)
• Contact type not in lookup (deleted from table but still in use)
• Company status mismatch (prospect with members-only designation)
• Individual Type not found (orphaned reference)
• Related company not found (orphaned reference)
• Company name too short/empty
• Individual name too short/empty
• Email format invalid
• Phone format invalid
• Zip code invalid
• Tax ID invalid format
• Company with no individuals (optional criterion)
• Duplicate contact types at same company (optional)
• Individual email matches another company's email (optional cross-company check)
• Company related to itself (self-reference)
• Inactive company with recent activity
• Portal user with no company assignment

Setup: John works at Company A and Company B. Company A invites him as MPA. He receives invite, creates portal account, logs in. Later, Company B (different chapter) also assigns him as MPA and sends invite.

What to Test:

• Can John use the same email for portal at both companies?
• Does John's existing password work for both companies, or does he set new password for Company B?
• Can John be logged into Company A and Company B portals simultaneously?
• If John logs into Company B portal, is he auto-logged out of Company A?
• If Company A disables portal, can John still access Company B portal?
• Can John manage both company profiles from a single portal dashboard, or does he need separate logins?

Setup: Company A has portal enabled. John (MPA) is logged into portal and actively editing company profile. Staff disables portal for Company A.

What to Test:

• John's active session: Does it end immediately or after timeout?
• Does John see a "session ended" message or is he silently logged out?
• If John refreshes page mid-edit, does he stay in editor or get booted to login?
• Can John's invitations (if pending) still be used?
• If Company A re-enables portal, does John automatically get re-invited?
• Are John's edits lost, saved, or partially saved?

Setup: Company A has portal enabled, 3 active portal users. Staff attempts to delete Company A.

What to Test:

• Deletion blocked: "Cannot delete — company has portal users with active sessions" or "Cannot delete — company has dependent records"?
• Should staff disable portal first, THEN delete? Or should deleting auto-logout users and clean up?
• Are portal users' accounts deleted, deactivated, or orphaned?
• If deletion allowed, what happens to portal invitations (pending invites for this company)?
• Can company be restored from trash/soft-delete if someone accidentally deleted it?

Setup: John's email is john@oldmail.com. Staff invites him to portal, sends invite email to john@oldmail.com. John receives invite. Before John clicks the link, his email changes to john@newmail.com (maybe he updates it himself, or moves to company).

What to Test:

• Is the invite still valid at the old email john@oldmail.com?
• If John clicks the old invite link, can he still set up portal?
• Should staff re-send invite to new email john@newmail.com?
• If John has already set password at old email, can he log in with new email?
• Are there two separate portal accounts (one for each email) or does email change seamlessly?
• If seamless, what happens to the old email's login credentials?

Setup: Company A has 3 CSI codes. Chapter staff configured Directory Proof max CSI = 5. Months later, chapter reduces max to 2. Company A now exceeds the limit.

What to Test:

• Does system auto-delete the oldest codes to bring Company A into compliance? (Probably NOT — data loss risk)
• Does system flag Company A in next audit as non-compliant?
• Can staff still add new codes to Company A, or is it blocked at add-time due to exceeding limit?
• Can MPA portal user see that the limit has changed?
• What message is shown to portal user when they try to add code and limit is exceeded?
• How does MPA fix this: By manually removing codes? Or can staff suspend the limit?

Setup: Staff accidentally enters market classification: Public=50%, Private=40% (missing Federal). Submits form.

What to Test:

• Form validation blocks submission with message showing current total and expected 100%?
• Or does system allow save and only catch error on audit?
• If caught on audit, what's the error message?
• Can portal MPA see the issue and fix it?
• If MPA tries to edit market classification, do they see current values and can add Federal to fix?
• What if staff deliberately sets percentages to < 100% to leave "buffer" for future additions?

Setup: Custom Business Designation "Preferred Partner" exists. 15 companies are marked with this designation. Staff deletes "Preferred Partner" from the lookup table (assuming it's not in use, or accidentally).

What to Test:

• Does system block deletion if value is in use? (Recommended for safety)
• If blocked, error message: "Cannot delete — used by 15 companies"?
• If deletion IS allowed, do the 15 companies still show "Preferred Partner" in their record?
• Or is "Preferred Partner" cleared from those records (data loss)?
• Can staff easily undo deletion (soft-delete with restore)?
• In portal, if MPA views company with now-deleted designation, can they see it or is it blank?

Setup: Company A and Company B are duplicates. Company A has 5 individuals, Company B has 3 individuals. 1 individual (John) exists at both companies. Staff wants to merge B into A.

What to Test:

• Does system support company merge operation at all?
• If yes, what happens to John (duplicate individual)? Merged, one deleted, or kept both?
• What happens to invoices/registrations/history tied to Company B?
• Does merged company retain both sets of individuals or does one company lose data?
• What about conflicting fields: Company A has Trade Codes "Concrete", Company B has "Steel". After merge, both? Or manual selection?
• If Company B has portal enabled and Company A doesn't, what happens to portal users?
• Can merge be undone?

• ☐ Create company with minimal data (name, status only)
• ☐ Create company with all optional fields (type, narrative, related companies)
• ☐ Company type defaults cascade correctly (user > chapter > national)
• ☐ Edit company name, description, status
• ☐ Edit company type, trade codes, market segments
• ☐ Change company status (Member > Prospect > Inactive)
• ☐ View change history shows all edits with user and timestamp
• ☐ Delete company with no dependents (invoices, registrations, history)
• ☐ Attempt delete company with invoices (blocked with clear error)
• ☐ Attempt delete company with event registrations (blocked with clear error)
• ☐ Attempt delete company with individuals (blocked)
• ☐ Attempt delete company with employment history (blocked)
• ☐ Bulk edit companies (if supported)
• ☐ Export company list with filtering
• ☐ Search companies by name, type, market segment
• ☐ Browse company roster with sorting/pagination

• ☐ Add individual to company with required fields (first name, last name, email)
• ☐ Informal name auto-populates from first name
• ☐ Informal name can be manually overridden
• ☐ Add individual with optional fields (phone, addresses, notes)
• ☐ Email uniqueness enforced within same company
• ☐ Same email allowed at different companies
• ☐ Inactive individual can share email with active individual (same company)
• ☐ Edit individual name, email, phone
• ☐ Add multiple addresses to individual
• ☐ Mark address as primary (only one allowed)
• ☐ Delete address (primary or non-primary)
• ☐ Move individual to different company (creates employment history)
• ☐ Delete individual with no history
• ☐ Attempt delete individual with employment history (blocked)
• ☐ View individual employment history
• ☐ Search individuals by name, email, company
• ☐ Bulk import individuals (if supported)

• ☐ Enable portal for company triggers auto-invite to MPAs
• ☐ Disable portal logs out all active users
• ☐ Confirm prompt shown when toggling portal on/off
• ☐ MPA receives invitation email with secure link
• ☐ Invitation link expires (default 7 days)
• ☐ Expired invitation link rejected with clear message
• ☐ MPA can re-request invitation if expired
• ☐ MPA clicks link, sets password, creates portal account
• ☐ Password meets requirements (length, complexity per config)
• ☐ MPA logs in with email and password
• ☐ Failed login attempts with error message
• ☐ Forgot password flow works (reset email sent, link valid)
• ☐ MPA can change password
• ☐ Session timeout after inactivity (configurable)
• ☐ Logout clears session
• ☐ Portal not accessible when disabled
• ☐ Portal not accessible to non-invited users

• ☐ MPA views company profile
• ☐ MPA edits company name (if allowed)
• ☐ MPA edits company narrative (respects character limit)
• ☐ MPA cannot edit company status (staff-only)
• ☐ MPA cannot create new companies (staff-only)
• ☐ MPA views all individuals in company
• ☐ MPA invites new individual to portal (if allowed)
• ☐ MPA edits existing individual record (email, phone, names)
• ☐ Email edit respects uniqueness constraints
• ☐ MPA cannot delete individuals (staff-only)
• ☐ MPA views change history of company/individuals
• ☐ MPA can export company profile
• ☐ Export includes all editable fields
• ☐ Limited user views company profile (read-only)
• ☐ Limited user cannot edit any fields

• ☐ MPA views current trade codes (CSI, NAICS)
• ☐ MPA adds CSI code to company
• ☐ Directory proof max CSI enforced (cannot exceed limit)
• ☐ MPA adds NAICS code to company
• ☐ Directory proof max NAICS enforced
• ☐ MPA removes trade code
• ☐ MPA views market segments (Public/Private/Federal, Commercial/Industrial/Residential)
• ☐ MPA edits market segment percentages
• ☐ Percentages must total 100% (validation at save-time or audit-time)
• ☐ Error message shows current total when not 100%
• ☐ Empty market classification allowed (optional)
• ☐ MPA can view but not edit national-only trade codes (if applicable)
• ☐ MPA can request new trade code if chapter-managed with approval workflow
• ☐ Requested codes pending approval not immediately available

• ☐ Create contact type (name, flag as MPA, flag as Primary)
• ☐ Edit contact type
• ☐ Delete contact type with no assignments
• ☐ Attempt delete contact type in use (blocked with error)
• ☐ Assign contact type to individual
• ☐ Individual can have multiple contact types at same company
• ☐ Only one primary contact type per individual (if enforced)
• ☐ Assigning "MPA" contact type to individual with portal ON triggers invite
• ☐ Assigning "MPA" with portal OFF does not trigger invite
• ☐ Bulk assign contact types (if supported)
• ☐ Change individual's contact type
• ☐ Remove contact type from individual
• ☐ Search individuals by contact type

• ☐ View national-only lookup values (cannot edit)
• ☐ Attempt edit national-only value (rejected with message)
• ☐ View national-approved values with approval status
• ☐ Request new national-approved value
• ☐ Pending request shows in queue
• ☐ National admin approves request
• ☐ Approved value becomes available in chapter
• ☐ National admin rejects request
• ☐ Rejected value removed from queue, chapter notified
• ☐ Edit chapter-managed values
• ☐ Add chapter-managed value
• ☐ Delete chapter-managed value with no usage
• ☐ Attempt delete chapter-managed value in use (blocked or allowed with data clearing?)
• ☐ Deleting value clears it from records using it (data integrity test)
• ☐ Chapter cannot see national admin's pending requests from other chapters

• ☐ Open audit creation form
• ☐ Select single audit criterion
• ☐ Select multiple audit criteria (all 31 available)
• ☐ Run audit with criteria selected
• ☐ Audit completes with results list
• ☐ Results show company/individual names and specific failures
• ☐ Results recommend fixes (e.g., "Add email to company")
• ☐ Missing company email criterion detects companies with no email
• ☐ Missing individual email criterion detects individuals with no email
• ☐ Duplicate individuals criterion detects same first+last name pairs
• ☐ Invalid trade code criterion catches codes not in lookup
• ☐ Market classification percentage criterion flags != 100% totals
• ☐ Directory proof exceeded criterion flags over-limit codes
• ☐ All 31 criteria execute correctly and without false positives
• ☐ Export audit results to CSV/Excel
• ☐ Re-run audit after fixes shows improvement
• ☐ Suppress/whitelist audit criterion for specific record (if feature exists)
• ☐ View audit history (previous runs, dates, results counts)

• ☐ Search companies by name (partial match works)
• ☐ Search companies by status (Member, Prospect, Inactive)
• ☐ Filter companies by type
• ☐ Filter companies by market segment
• ☐ Filter companies by trade code
• ☐ Filter companies by business designation
• ☐ Combine multiple filters (AND logic)
• ☐ Search individuals by name
• ☐ Search individuals by email
• ☐ Filter individuals by contact type
• ☐ Filter individuals by company
• ☐ Filter individuals by status (active, inactive)
• ☐ Export company list to CSV/Excel
• ☐ Export includes selected columns
• ☐ Export respects applied filters (only showing filtered companies)
• ☐ Export individuals with contact types
• ☐ Export preserves special characters, line breaks
• ☐ Bulk send outreach email to filtered contact list (if feature exists)

• ☐ Staff without Contacts permission cannot create company (shows forbidden)
• ☐ Staff with Contacts permission can create company
• ☐ Portal user cannot create company
• ☐ MPA can edit company profile (certain fields)
• ☐ MPA cannot edit company status
• ☐ MPA cannot delete company
• ☐ Registration-level portal user can view company (read-only certain fields)
• ☐ Limited portal user can only view, no edit
• ☐ Limited user form fields appear read-only
• ☐ Limited user sees no delete buttons
• ☐ Portal user cannot see staff-only audit reports
• ☐ Portal user cannot change portal settings
• ☐ Portal user cannot manage other portal users (unless MPA)
• ☐ Permission changes take effect immediately (no cache staleness)
• ☐ Permission denials show helpful error messages (not 403 error codes)

• ☐ Individual cannot exist without company assignment
• ☐ Moving individual to new company creates employment history
• ☐ Employment history preserved when individual deleted (if no delete allowed)
• ☐ Contact type assignment creates audit entry
• ☐ Contact type removal creates audit entry
• ☐ Company status change tracked in change history
• ☐ All edits include timestamp and editor name
• ☐ No orphaned individuals (all linked to valid company)
• ☐ No orphaned contact types (all reference valid types in lookup)
• ☐ No duplicate individuals (true, unique identifiers)
• ☐ Related companies references are valid (no broken links)
• ☐ Trade code references valid (deleted codes cleared from records)
• ☐ Business designation references valid
• ☐ Individual type references valid
• ☐ Email uniqueness enforced across all operations (admin, portal, API)
• ☐ No data loss on edit (previous values preserved for undo/history)
• ☐ Cascade delete handled safely (no orphaned records)
• ☐ Concurrent edits handled (last-write-wins or merge conflict?)

Sandbox Environment Setup:

• ABC Contacts module installed and activated
• Portal feature enabled (not disabled)
• Email/SMTP configured for portal invitations and notifications
• Multiple chapters configured (to test cross-chapter scenarios)
• Lookup tables configured (trade codes, business designations, individual types)
• Directory Proof limits set per chapter (CSI max, NAICS max)
• Market classification groups configured (Public/Private/Federal, Commercial/Industrial/Residential)
• Test user accounts created with various permission levels:
• Admin (full access to all chapters)
• Contacts Permission (can create/edit/delete companies and individuals)
• Read-only Staff (view-only access)
• Member Portal Admin (via invitation)
• Portal Individual with Registration permission
• Portal Individual with Limited permission
• Anonymous/unauthenticated user (public access, if applicable)
• Test email inbox configured for capturing portal invitations
• Test database seeded with base data (see Data Prerequisites below)
• API access configured (if API testing required)

Base Data to Create:

• Chapters: At least 2 chapters (to test cross-chapter scenarios)
• Chapter A: Portal enabled, Directory Proof max CSI=3, max NAICS=3
• Chapter B: Portal disabled initially (for enable/disable testing), different Directory Proof limits
• Companies (mixed statuses):
• Member Company A: Portal enabled, 5 individuals with various contact types
• Member Company B: Portal disabled, 3 individuals
• Prospect Company C: No portal, 1 individual
• Inactive Company D: 2 individuals
• Company with minimal data (name + status only)
• Company with all fields populated (type, narrative, related companies, trade codes, market segments)
• Individuals (various scenarios):
• Individual with multiple contact types at same company
• Individual with multiple addresses (primary and non-primary)
• Individual with employment history (moved between companies)
• Duplicate-name individuals (same first/last, different companies)
• Inactive individual
• Individual with portal account (MPA)
• Individual with multiple portal accounts (at different companies)
• Contact Types:
• Owner (flagged as MPA)
• Controller
• Project Manager
• Office Manager
• Sales Contact
• Trade Codes:
• National-only CSI codes (e.g., 033000 — Concrete Forming, Shoring, Bracing, and Removing)
• Chapter-approved NAICS codes (pending approval)
• Chapter-managed trade codes
• Trade codes at directory proof limits
• Business Designations:
• National: Union, Certified, Bonded
• Chapter-managed: Preferred Partner, Small Business
• Company Relationships:
• Parent/Subsidiary relationship (Company A parent, Company B subsidiary)
• Peer/Related companies

Between Test Cycles:

• Delete all test companies created during cycle (preserve base data)
• Clear all test individuals and contact assignments
• Reset portal invitations (clear pending, invalidate sessions)
• Reset contact audit results
• Clear audit history logs if running volume tests
• Reset lookup table test values to known state
• Verify no orphaned records remain in database

Database Cleanup:

• Preserve base data companies, individuals, contact types
• Remove all test-created related company links
• Clear test employment history records
• Remove test-created trade code assignments
• Reset market classification data
• Clear change history logs older than 30 days (optional)
• Verify no duplicate individual records
• Verify all contact type references valid

Portal Cleanup:

• Clear all test portal user accounts
• Clear pending portal invitations
• Disable portal for all test companies
• Reset portal session tokens
• Clear portal audit logs (optional)

Regression Cycle Setup:

• Scenario 1: Basic Company & Individual
• Company: "ABC Concrete Co", Member status, Type: Contractor
• Individual: John Smith, Email: john@abcconcrete.com, Contact Type: Owner
• Portal: Disabled initially
• Data Quality: All fields complete, valid emails, no duplicates
• Scenario 2: Complex Company with Portal
• Company: "National Steel Corp", Member status, Type: Subcontractor
• Portal: Enabled
• Individuals: 5 people with multiple contact types
• Trade Codes: 3 CSI + 2 NAICS (at directory proof limits)
• Market Segments: Commercial=60%, Industrial=30%, Residential=10%
• Business Designations: Union, Bonded
• Scenario 3: Prospect Company (Pre-Member)
• Company: "Future Builder Inc", Prospect status
• Individuals: 2 contacts (no contact types yet)
• Trade Codes: None yet
• Portal: Disabled
• Scenario 4: Company With Employment History
• Company A: "Original Company"
• Company B: "New Company"
• Individual: Jane Doe, moved from Company A to Company B (test employment history)
• Scenario 5: Multi-Company Portal User
• Company A & Company B (different chapters): Both portal-enabled
• Individual: Bob Smith, MPA at both companies
• Test: Can Bob log in to both portals, manage both companies

Scale Tests (if applicable):

• 100+ companies with 500+ individuals (test search/filter performance)
• Company with 50+ individuals (test roster page loading)
• Individual with 10+ addresses (test address management UI)
• Contact audit on 1000+ records with all 31 criteria (test audit engine performance)
• Portal with 100+ simultaneous users editing company data (concurrency)
• 1000+ trade codes in dropdown (UI responsiveness)

Edge Case Data:

• Very long company names (100+ characters)
• Very long company narrative (at/exceeding character limits)
• Special characters in names (accents, symbols)
• International addresses (non-US countries)
• Null/empty optional fields (test graceful handling)
• Deleted lookup values with 100+ record references (test cleanup)

Stress Tests:

• Rapid company creation (100 in sequence)
• Bulk individual import (500 individuals)
• Multiple concurrent portal invitations sent
• Portal enable/disable toggled rapidly (race condition detection)
• Concurrent contact type assignments to same individual
• Large export (1000+ records to CSV)