Review how proposed changes map to detected issues, then explore the before/after schema diff grouped by table.
Cross-reference
Compare with current schema
Check the original structure and issue report before applying changes.
Export the current redesign as a concise brief that stays coherent even when optional sections are unavailable, or open the full report when you need findings, evidence, proposal scope, and migration guidance in one printable artifact.
Northstar Agency Ops Demo currently carries 22 deterministic findings. The recommended "Balanced redesign" redesign packages 20 changes that fully resolve 9 issues and leaves 13 for later follow-up.
Issues addressed
9/22
Changes in scope
20
Migration phases
2
Preview gains
17
Export notes
Generated from the current deterministic redesign workspace. Missing sections are called out explicitly so the brief stays coherent when optional layers are absent.
Open print view22 deterministic issues were found. The recommended redesign fully resolves 9 and partially mitigates 0.
20 deterministic changes are grouped into 4 reusable change sets. The recommended path is "Balanced redesign".
20 steps are ordered across 2 phases so additive work lands before modification and structural cleanup.
17 migration steps improve or enable generated dashboard, form, or portal outputs.
The recommended path scores high complexity, high future flexibility, and medium migration cost.
Reusable change sets are combined into multiple defensible redesign paths. The recommended variant stays the default below, while alternatives remain visible for tradeoff review.
Variant comparison
2
proposal variants
4
reusable change sets
20
changes in the default path
9
issues addressed below
The sections below use Balanced redesign as the default path. Alternatives stay visible here so tradeoffs remain explicit.
Apply the full deterministic proposal bundle, including the shared People model when entity drift is strong enough to justify it.
Complexity
HighFuture flexibility
HighMigration cost
MediumBest long-term structure and reuse, but the shared People model increases migration breadth.
Included change sets
Keep improvements inside the current tables and defer cross-table people normalization to a later migration window.
Complexity
HighFuture flexibility
MediumMigration cost
MediumLower disruption now, but person references stay duplicated until a later normalization pass.
Included change sets
Deferred in this variant
These bundles can be reused across multiple redesign strategies so the system can recombine the same deterministic fixes without duplicating proposal logic.
Standardize the operational lifecycle so workflow tables gain timestamps, due dates, and cleaner status values.
Low-friction field additions and lifecycle normalization remove ambiguity before deeper structural changes.
Add explicit ownership fields so work can be assigned and workload views stay reliable.
Operational tables without an owner field are harder to route, review, and summarize consistently.
Replace drift-prone text categories with controlled vocabularies and stronger field types.
Normalization reduces reporting fragmentation and improves generated forms, filters, and dashboards.
Introduce a shared People model so owner, assignee, and approver references can stop drifting as free text.
This is the most flexible long-term structure, but it asks the team to absorb a broader migration step now.
Each issue from the analysis is classified as resolved, partially mitigated, or unresolved based on whether a proposed change directly addresses it.
Resolution coverage
22
total issues
9
resolved
0
partially mitigated
13
unresolved
Resolution by category
Schema
Workflow
Data
UX
9 issues
Requests.Category is modeled as free text even though it looks categorical.
Convert the field to single select or multi-select and backfill the existing values into a controlled option set.
1 proposal resolve this
People involved in delivery are stored as plain text across multiple tables instead of a normalized entity.
Create a dedicated People table or use collaborator fields, then replace repeated text references with linked records.
4 proposals resolve this
Projects.Status has 11 states, which is more than the recommended workflow limit.
Collapse adjacent statuses into a smaller lifecycle or split planning-only states into a separate field if they truly serve a different purpose.
1 proposal resolve this
Requests tracks workflow state but has no owner or assignee field.
Add an owner or assignee field, ideally as a collaborator or linked People record, so each item has clear accountability.
1 proposal resolve this
Approvals behaves like a workflow table but has no due date or deadline field.
Add a due date, deadline, or SLA field so time-based reporting and reminders can work consistently.
1 proposal resolve this
Requests behaves like a workflow table but has no due date or deadline field.
Add a due date, deadline, or SLA field so time-based reporting and reminders can work consistently.
1 proposal resolve this
Requests.Category shows value drift across the sample data instead of a stable vocabulary.
Normalize the current values into a controlled option set or linked taxonomy table, then migrate existing records to the approved labels.
1 proposal resolve this
The sample data repeats the same people names across text fields instead of referencing a shared entity.
Move team members or approvers into collaborator fields or a dedicated People table, then replace repeated text entries with references.
4 proposals resolve this
Several tables are missing explicit created/updated audit fields.
Add Created Time plus Last Modified Time fields to operational tables so records can be sorted and monitored reliably.
10 proposals resolve this
13 issues
The field name "Status" is reused across tables with different meanings.
Rename overloaded fields or align them to a shared lifecycle model so the same label means the same thing everywhere.
Approvals.Date is missing in 2 of 5 sampled records.
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Some primary fields use generic labels that do not explain the record identity at a glance.
Use more descriptive primary field labels or compose them from the entity plus its distinguishing detail.
Projects.Owner is missing in 2 of 7 sampled records.
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Tasks.Assignee is missing in 2 of 8 sampled records.
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Tasks.Due Date is missing in 2 of 8 sampled records.
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Approvals suggests a repeatable approval workflow that could be surfaced as a dedicated experience.
Generate an approval-oriented portal or detail view that emphasizes deliverable status, reviewer actions, and decision history.
Approvals has the structure needed for a kanban or workload dashboard.
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Projects has the structure needed for a kanban or workload dashboard.
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Requests has the structure needed for a kanban or workload dashboard.
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Tasks has the structure needed for a kanban or workload dashboard.
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Requests looks like an intake surface that could be captured through a guided form experience.
Generate a field-aware intake form for this table, hiding internal fields and emphasizing the information an external requester actually needs.
Several tables contain client, status, and timeline signals that would translate well into a client-facing view.
Generate a client portal preview centered on project progress, request status, approvals, and upcoming dates.
Before/after comparison of proposed changes, grouped by table.
Proposal summary
20
total changes
5
tables affected
5
fields affected
9
issues addressed
2 proposed changes
Before
—
After
Created Time (createdTime)
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Before
—
After
Last Modified (lastModifiedTime)
Tracking last modification helps identify stale records and powers recency-based views.
4 proposed changes
Before
—
After
Created Time (createdTime)
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Before
—
After
Last Modified (lastModifiedTime)
Tracking last modification helps identify stale records and powers recency-based views.
Before
After
Not Started, In Progress, In Review, Blocked
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
Before
—
After
Link to People
Replace free-text "Owner" with a linked record to the People table for consistent references.
3 proposed changes
Before
—
After
Created Time (createdTime)
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Before
—
After
Last Modified (lastModifiedTime)
Tracking last modification helps identify stale records and powers recency-based views.
Before
—
After
Link to People
Replace free-text "Assignee" with a linked record to the People table for consistent references.
6 proposed changes
Before
—
After
Created Time (createdTime)
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Before
—
After
Last Modified (lastModifiedTime)
Tracking last modification helps identify stale records and powers recency-based views.
Before
—
After
Due Date (date)
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Before
—
After
Owner (singleCollaborator)
Every workflow table should have clear ownership for routing, accountability, and workload views.
Before
Category: singleLineText
After
Category: singleSelect
Fields with categorical values should use select types for consistent filtering, grouping, and generated controls.
Before
Website update, Branding, brand refresh, Presentation
After
Brand Refresh, Branding, Presentation, Web Update
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
4 proposed changes
Before
—
After
Created Time (createdTime)
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Before
—
After
Last Modified (lastModifiedTime)
Tracking last modification helps identify stale records and powers recency-based views.
Before
—
After
Due Date (date)
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Before
—
After
Link to People
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
1 proposed change
Before
—
After
People (3 fields)
Centralizing team members into a dedicated table eliminates duplicate spellings and enables reliable workload and ownership reporting.
Ordered execution plan with safe additive changes first and risky structural changes last. Steps requiring manual review are flagged.
Migration overview
2
phases
20
total steps
17
safe
3
moderate
0
risky
1 step require manual review before execution.
17 steps
SafeSafe additive changes that introduce new structures without altering existing data.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Every workflow table should have clear ownership for routing, accountability, and workload views.
Replace free-text "Owner" with a linked record to the People table for consistent references.
Depends on: add-table:people
Replace free-text "Assignee" with a linked record to the People table for consistent references.
Depends on: add-table:people
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
Depends on: add-table:people
Centralizing team members into a dedicated table eliminates duplicate spellings and enables reliable workload and ownership reporting.
3 steps
Moderate risk(1 need review)Moderate-risk changes that rename or convert existing fields. Automations and formulas referencing old names may need updating.
Fields with categorical values should use select types for consistent filtering, grouping, and generated controls.
Converting "Category" from singleLineText to singleSelect may cause data loss if existing values are incompatible.
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
Estimated effort, breakage risk, and which generated dashboards, forms, or portals improve if each change is applied. Deterministic signals are shown as solid; AI-assisted estimates use dashed styling.
Impact overview
17
low effort
3
medium effort
0
high effort
17
affect previews
17 steps improve or enable dashboard, form, or portal previews
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Tracking last modification helps identify stale records and powers recency-based views.
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Every workflow table should have clear ownership for routing, accountability, and workload views.
Replace free-text "Owner" with a linked record to the People table for consistent references.
Fields with categorical values should use select types for consistent filtering, grouping, and generated controls.
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
3 steps with no direct preview impact
Replace free-text "Assignee" with a linked record to the People table for consistent references.
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
Centralizing team members into a dedicated table eliminates duplicate spellings and enables reliable workload and ownership reporting.
This layer remains suggestion-first. It labels which changes are additive candidates for a future consented write flow, which stay preview-only, and which must remain manual migration work.
Guardrails
This workspace is still read-only. The write-back layer only labels what could eventually be assisted, what stays preview-only, and what must remain manual.
Phase 5 remains suggestion-first. Automatic Airtable schema writes are disabled.
The current integration is read-only. Any future write path must require a separate scope upgrade and per-batch confirmation.
Manual-only changes stay outside assisted write-back because they can remove data, break references, or require record-level cleanup.
20
suggested changes
17
future-assisted candidates
2
preview-only changes
1
manual-only migrations
These explicit confirmations define the minimum bar before any future write-capable flow could exist. Today they are documentation, not execution controls.
Upgrade from read-only access
Future-assisted candidateAny future assisted write flow must be behind a separate write-capable integration grant. The current app session stays read-only.
Approve the exact schema diff
Future-assisted candidatePreview onlyManual onlyThe reviewed table and field diff must match the batch being executed. No hidden or implied changes are allowed.
Capture a fresh schema snapshot
Future-assisted candidateManual onlyA new snapshot is required immediately before any execution attempt so stale proposals cannot be replayed against a changed base.
Review formulas, automations, and views
Preview onlyManual onlyAffected tables must be checked for downstream dependencies before anything beyond additive creation is attempted.
Assign rollback ownership
Manual onlyA human owner must confirm rollback or export coverage before any destructive or data-shaping migration proceeds.
Future write capability would need to stay inside a narrow reviewed scope. The model below makes the allowed change types and prohibited actions explicit.
Scoped field creation only
Requires future scope upgradeCreate new fields on explicitly reviewed tables without renaming, deleting, or converting existing schema.
Not allowed: Renaming existing fields
Not allowed: Deleting fields or tables
Not allowed: Changing field types
Scoped additive tables and links
Requires future scope upgradeAdd reviewed helper tables and linked-record fields only after the target tables are confirmed in the preview.
Not allowed: Backfilling records automatically
Not allowed: Replacing existing links
Not allowed: Removing legacy structures
Preview-only planning lane
Show renames and taxonomy cleanup as reviewed diffs, but keep them non-executable until stronger dependency and data-shaping safeguards exist.
Not allowed: Applying schema mutations from this assistant
Not allowed: Silent value rewrites
Not allowed: Running backfills without human review
Manual migration only
Destructive or high-risk restructures stay outside any assisted write path and must be executed manually with human supervision.
Not allowed: Automatic execution
Not allowed: One-click destructive changes
Not allowed: Unreviewed data conversion
17 changes. Safe additive changes that could become executable later, but only after an explicit write-capable opt-in flow is built.
Add "Created Time"
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Last Modified"
Tracking last modification helps identify stale records and powers recency-based views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Created Time"
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Last Modified"
Tracking last modification helps identify stale records and powers recency-based views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Created Time"
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Last Modified"
Tracking last modification helps identify stale records and powers recency-based views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Created Time"
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Last Modified"
Tracking last modification helps identify stale records and powers recency-based views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Created Time"
Operational tables benefit from automatic timestamps for sorting, recency filters, and audit trails.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Last Modified"
Tracking last modification helps identify stale records and powers recency-based views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Due Date"
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Due Date"
Workflow tables need a target date for prioritization, overdue tracking, and timeline views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "Owner"
Every workflow table should have clear ownership for routing, accountability, and workload views.
Candidate for a future scoped create-field flow after explicit write consent.
Any future execution must stay inside "Scoped field creation only" and cannot widen into renames, deletions, or conversions.
Add "People" table
Centralizing team members into a dedicated table eliminates duplicate spellings and enables reliable workload and ownership reporting.
Candidate for a future assisted additive schema flow once the reviewed scope is locked.
Any future execution must stay inside "Scoped additive tables and links" and cannot widen into renames, deletions, or conversions.
Add "Owner (linked)" link
Replace free-text "Owner" with a linked record to the People table for consistent references.
Candidate for a future assisted additive schema flow once the reviewed scope is locked.
Any future execution must stay inside "Scoped additive tables and links" and cannot widen into renames, deletions, or conversions.
Link creation may still require manual record backfill and post-create validation before it becomes useful.
Add "Assignee (linked)" link
Replace free-text "Assignee" with a linked record to the People table for consistent references.
Candidate for a future assisted additive schema flow once the reviewed scope is locked.
Any future execution must stay inside "Scoped additive tables and links" and cannot widen into renames, deletions, or conversions.
Link creation may still require manual record backfill and post-create validation before it becomes useful.
Add "Approver Name (linked)" link
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
Candidate for a future assisted additive schema flow once the reviewed scope is locked.
Any future execution must stay inside "Scoped additive tables and links" and cannot widen into renames, deletions, or conversions.
Link creation may still require manual record backfill and post-create validation before it becomes useful.
2 changes. Keep these changes in the reviewed diff. They touch existing semantics and should not auto-execute from this workspace.
Normalize "Status" values
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
Keep this as a reviewed diff only. Additional dependency and data-shaping safeguards are required before any execution is considered.
This change affects existing semantics, so it remains preview-only until downstream references and value-migration rules can be audited.
Normalize "Category" values
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
Keep this as a reviewed diff only. Additional dependency and data-shaping safeguards are required before any execution is considered.
This change affects existing semantics, so it remains preview-only until downstream references and value-migration rules can be audited.
1 change. High-risk changes that remain human-run migration work, even if the product eventually supports a narrower assisted path.
Convert "Category" type
Fields with categorical values should use select types for consistent filtering, grouping, and generated controls.
This change should stay manual. Use the suggestion as migration guidance, not as an executable action.
Converting "Category" from singleLineText to singleSelect may cause data loss if existing values are incompatible.
Representative rows show what gets backfilled automatically, what is normalized, and where manual cleanup still matters in the proposed structure.
Representative record mapping
9 representative records across 4 tables show how the recommended redesign changes field structure and backfill work.
Requests preview focuses on value cleanup plus field-type hardening for representative rows.
6 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-11
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
(new field)
(not present)
Proposed
Due Date
Needs manual backfill
No reliable due-date source was found in the sampled record.
Current
(new field)
(not present)
Proposed
Owner
Needs assignment
The sampled record does not carry a reliable owner value yet.
Current
Category
Website update
Proposed
Category
Website Update
Type shifts from singleLineText to singleSelect.
Current
Category
Website update
Proposed
Category
Website Update
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
6 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-14
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
(new field)
(not present)
Proposed
Due Date
Needs manual backfill
No reliable due-date source was found in the sampled record.
Current
(new field)
(not present)
Proposed
Owner
Needs assignment
The sampled record does not carry a reliable owner value yet.
Current
Category
Presentation
Proposed
Category
Presentation
Type shifts from singleLineText to singleSelect.
Current
Category
Presentation
Proposed
Category
Presentation
High-drift text values should be consolidated into a controlled vocabulary so reports and filters stay consistent.
Projects preview shows how free-text references would move into linked-record structure.
4 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-01
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
Status
Client Review
Proposed
Status
In Review
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
Current
Owner
Dylan
Proposed
Owner (linked)
People -> Dylan
Replace free-text "Owner" with a linked record to the People table for consistent references.
4 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-02
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
Status
In Progress
Proposed
Status
In Progress
Overly granular status values fragment reporting and make boards harder to scan. Consolidating to a smaller lifecycle improves clarity.
Current
Owner
Priya
Proposed
Owner (linked)
People -> Priya
Replace free-text "Owner" with a linked record to the People table for consistent references.
Approvals preview shows how free-text references would move into linked-record structure.
4 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-20
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
(new field)
(not present)
Proposed
Due Date
2026-03-28
Suggested from the linked project due date for migration planning.
Current
Approver Name
Maya Chen
Proposed
Approver Name (linked)
People -> Maya Chen
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
4 projected field changes for this representative record.
Current
(new field)
(not present)
Proposed
Created Time
2026-02-21
Backfill with Airtable record created time.
Current
(new field)
(not present)
Proposed
Last Modified
Auto-populates on the next edit
Initial export shows the field empty until Airtable records a change.
Current
(new field)
(not present)
Proposed
Due Date
2026-04-02
Suggested from the linked project due date for migration planning.
Current
Approver Name
Jordan Alvarez
Proposed
Approver Name (linked)
People -> Jordan Alvarez
Replace free-text "Approver Name" with a linked record to the People table for consistent references.
Centralizes 10 repeated person references that currently live as free text across operational tables.
Derived from 2 existing text references.
Current
Free-text references
Projects.Owner | Tasks.Assignee
Proposed
Name
Ava
Primary People record generated from repeated names in existing workflow tables.
Current
(new field)
(not present)
Proposed
Role
Team member
Suggested from the source fields that currently hold the name.
Current
(new field)
(not present)
Proposed
Needs directory match
Email is not inferable from the sampled operational rows.
Derived from 2 existing text references.
Current
Free-text references
Projects.Owner | Tasks.Assignee
Proposed
Name
Dylan
Primary People record generated from repeated names in existing workflow tables.
Current
(new field)
(not present)
Proposed
Role
Team member
Suggested from the source fields that currently hold the name.
Current
(new field)
(not present)
Proposed
Needs directory match
Email is not inferable from the sampled operational rows.
Derived from 2 existing text references.
Current
Free-text references
Projects.Owner | Tasks.Assignee
Proposed
Name
Marta
Primary People record generated from repeated names in existing workflow tables.
Current
(new field)
(not present)
Proposed
Role
Team member
Suggested from the source fields that currently hold the name.
Current
(new field)
(not present)
Proposed
Needs directory match
Email is not inferable from the sampled operational rows.
Explore the exact evidence behind each finding and proposal. Profile metrics, sample values, and schema locations are linked to the analysis that produced them.
Evidence summary
5
Tables
32
Fields
32
Records
0.8
Link density
0
Isolated
Requests.Category is modeled as free text even though it looks categorical.
+Why it matters
Categorical values stored in text fields drift over time, making grouping, filtering, and generated controls inconsistent.
Suggested fix
Convert the field to single select or multi-select and backfill the existing values into a controlled option set.
Field profile: Category
0%
Null rate
100%
Distinct ratio
6
Total values
No
Categorical
Top values
Sample values
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
The field name "Status" is reused across tables with different meanings.
+Why it matters
Shared field names that represent different workflows make filters, documentation, and generated UI harder to trust.
Suggested fix
Rename overloaded fields or align them to a shared lifecycle model so the same label means the same thing everywhere.
Supporting evidence
People involved in delivery are stored as plain text across multiple tables instead of a normalized entity.
+Why it matters
Free-text people fields create duplicate spellings, weaken reporting, and make generated assignments or workload views unreliable.
Suggested fix
Create a dedicated People table or use collaborator fields, then replace repeated text references with linked records.
Supporting evidence
Projects.Status has 11 states, which is more than the recommended workflow limit.
+Why it matters
Large status lists slow down triage, create near-duplicate states, and make dashboards harder to interpret.
Suggested fix
Collapse adjacent statuses into a smaller lifecycle or split planning-only states into a separate field if they truly serve a different purpose.
Field profile: Status
0%
Null rate
100%
Distinct ratio
7
Total values
No
Categorical
Top values
Sample values
Table context: Projects
7
Records
8
Fields
1
Link fields
Role
Requests tracks workflow state but has no owner or assignee field.
+Why it matters
Workflow tables without ownership make queues harder to route and make generated workload views incomplete.
Suggested fix
Add an owner or assignee field, ideally as a collaborator or linked People record, so each item has clear accountability.
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
Approvals behaves like a workflow table but has no due date or deadline field.
+Why it matters
Operational work without a target date is hard to prioritize, escalate, or surface in overdue views.
Suggested fix
Add a due date, deadline, or SLA field so time-based reporting and reminders can work consistently.
Table context: Approvals
5
Records
6
Fields
1
Link fields
Role
Requests behaves like a workflow table but has no due date or deadline field.
+Why it matters
Operational work without a target date is hard to prioritize, escalate, or surface in overdue views.
Suggested fix
Add a due date, deadline, or SLA field so time-based reporting and reminders can work consistently.
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
Requests.Category shows value drift across the sample data instead of a stable vocabulary.
+Why it matters
When near-categorical values stay as free text, reports fragment, filters become unreliable, and generated controls cannot trust the underlying options.
Suggested fix
Normalize the current values into a controlled option set or linked taxonomy table, then migrate existing records to the approved labels.
Supporting evidence
Field profile: Category
0%
Null rate
100%
Distinct ratio
6
Total values
No
Categorical
Top values
Sample values
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
Approvals.Date is missing in 2 of 5 sampled records.
+Why it matters
High-null operational fields weaken filtering, reporting, and generated UI because important context is missing when records are viewed in bulk.
Suggested fix
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Supporting evidence
Field profile: Date
40%
Null rate
67%
Distinct ratio
5
Total values
No
Categorical
Top values
Sample values
Table context: Approvals
5
Records
6
Fields
1
Link fields
Role
The sample data repeats the same people names across text fields instead of referencing a shared entity.
+Why it matters
Repeated free-text names invite spelling drift and prevent dependable workload, ownership, and approval reporting across tables.
Suggested fix
Move team members or approvers into collaborator fields or a dedicated People table, then replace repeated text entries with references.
Supporting evidence
Several tables are missing explicit created/updated audit fields.
+Why it matters
Without audit metadata, it is harder to debug stale records, build recency-based views, or explain when work changed.
Suggested fix
Add Created Time plus Last Modified Time fields to operational tables so records can be sorted and monitored reliably.
Supporting evidence
Some primary fields use generic labels that do not explain the record identity at a glance.
+Why it matters
Ambiguous primary fields make linked records, search results, and generated previews less legible for end users.
Suggested fix
Use more descriptive primary field labels or compose them from the entity plus its distinguishing detail.
Supporting evidence
Projects.Owner is missing in 2 of 7 sampled records.
+Why it matters
High-null operational fields weaken filtering, reporting, and generated UI because important context is missing when records are viewed in bulk.
Suggested fix
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Supporting evidence
Field profile: Owner
29%
Null rate
80%
Distinct ratio
7
Total values
No
Categorical
Top values
Sample values
Table context: Projects
7
Records
8
Fields
1
Link fields
Role
Tasks.Assignee is missing in 2 of 8 sampled records.
+Why it matters
High-null operational fields weaken filtering, reporting, and generated UI because important context is missing when records are viewed in bulk.
Suggested fix
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Supporting evidence
Field profile: Assignee
25%
Null rate
83%
Distinct ratio
8
Total values
No
Categorical
Top values
Sample values
Table context: Tasks
8
Records
6
Fields
1
Link fields
Role
Tasks.Due Date is missing in 2 of 8 sampled records.
+Why it matters
High-null operational fields weaken filtering, reporting, and generated UI because important context is missing when records are viewed in bulk.
Suggested fix
Decide whether this field is truly optional. If not, backfill missing values and add defaults, automation, or process guardrails to keep it populated.
Supporting evidence
Field profile: Due Date
25%
Null rate
100%
Distinct ratio
8
Total values
No
Categorical
Top values
Sample values
Table context: Tasks
8
Records
6
Fields
1
Link fields
Role
Approvals suggests a repeatable approval workflow that could be surfaced as a dedicated experience.
+Why it matters
Approval steps are easier to understand when approvers get a focused review surface instead of raw Airtable rows and internal fields.
Suggested fix
Generate an approval-oriented portal or detail view that emphasizes deliverable status, reviewer actions, and decision history.
Supporting evidence
Table context: Approvals
5
Records
6
Fields
1
Link fields
Role
Approvals has the structure needed for a kanban or workload dashboard.
+Why it matters
Tables with clear statuses, ownership, and deadlines benefit from visual views that make blocked work and capacity issues obvious.
Suggested fix
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Supporting evidence
Field profile: Decision
0%
Null rate
60%
Distinct ratio
5
Total values
No
Categorical
Top values
Sample values
Table context: Approvals
5
Records
6
Fields
1
Link fields
Role
Projects has the structure needed for a kanban or workload dashboard.
+Why it matters
Tables with clear statuses, ownership, and deadlines benefit from visual views that make blocked work and capacity issues obvious.
Suggested fix
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Supporting evidence
Field profile: Status
0%
Null rate
100%
Distinct ratio
7
Total values
No
Categorical
Top values
Sample values
Table context: Projects
7
Records
8
Fields
1
Link fields
Role
Requests has the structure needed for a kanban or workload dashboard.
+Why it matters
Tables with clear statuses, ownership, and deadlines benefit from visual views that make blocked work and capacity issues obvious.
Suggested fix
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Supporting evidence
Field profile: Status
0%
Null rate
83%
Distinct ratio
6
Total values
No
Categorical
Top values
Sample values
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
Tasks has the structure needed for a kanban or workload dashboard.
+Why it matters
Tables with clear statuses, ownership, and deadlines benefit from visual views that make blocked work and capacity issues obvious.
Suggested fix
Create a generated dashboard or kanban preview that groups records by status and highlights due dates or unassigned work.
Supporting evidence
Field profile: Status
0%
Null rate
75%
Distinct ratio
8
Total values
No
Categorical
Top values
Sample values
Table context: Tasks
8
Records
6
Fields
1
Link fields
Role
Requests looks like an intake surface that could be captured through a guided form experience.
+Why it matters
Structured intake reduces field omissions, keeps requests consistent, and creates a smoother path into the rest of the workflow.
Suggested fix
Generate a field-aware intake form for this table, hiding internal fields and emphasizing the information an external requester actually needs.
Supporting evidence
Table context: Requests
6
Records
7
Fields
1
Link fields
Role
Several tables contain client, status, and timeline signals that would translate well into a client-facing view.
+Why it matters
A read-only portal can reduce status update churn and give external stakeholders a cleaner way to follow work without exposing internal operations.
Suggested fix
Generate a client portal preview centered on project progress, request status, approvals, and upcoming dates.
Supporting evidence
AI-generated root-cause grouping, remediation planning, and missing-risk identification. These insights are clearly labeled by verification level and kept separate from deterministic findings.
This agency project-management base has strong foundational structure with clear table roles, but lacks audit trails, uses free-text for people references, and has inconsistent status vocabularies across tables. The highest-impact fix is adding audit timestamps (non-breaking), followed by creating a People table to replace text-based owner fields. These two changes alone would resolve most critical and warning-level findings.
Was this AI guidance helpful?
Stored separately from deterministic findings so AI tuning does not affect the baseline analysis record.
Was this AI guidance helpful?
Stored separately from deterministic findings so AI tuning does not affect the baseline analysis record.
Was this AI guidance helpful?
Stored separately from deterministic findings so AI tuning does not affect the baseline analysis record.
Was this AI guidance helpful?
Stored separately from deterministic findings so AI tuning does not affect the baseline analysis record.