Define the record
Agree on what a project, task and team mean in your workflow. Use stable identifiers so a renamed project can still be linked to its history and dependencies.
Data Model
Your work, structured around your team.
Bring projects, teams and tasks into a consistent model without flattening the way you work.
ACDFMC+1
Illustrative workspace · interactive demonstration
Make relationships explicit
Link projects to teams, tasks and accountable owners.
ENG-284Linked context
Keep useful attributes
Keep custom fields for scope, priority and release constraints.
Review the range
Review every import
Check source, timestamp and duplicates before accepting changes.
Ready for reviewHuman approval
A practical workflow
Give every record a place in the plan.
A consistent model helps a team compare projects without losing the details that make each project different.
Map the useful fields
Carry over the owner, status, scope and target date that support a planning decision. Keep source names and timestamps with the mapping so conflicting values can be investigated.
Review the working view
Filter the demonstration by status or owner, inspect the selected records and export the visible rows. Use the view to discuss exceptions before accepting an import into a real workspace.
A connected working example
Find the projects that need a closer look.
The Meridian projects table brings ownership, delivery confidence and deadline context into the same row. A delivery lead can narrow the view to an owner or status before opening a project discussion.
A clean table is only the beginning. Relationships connect that row to the actual tasks and decisions behind it. Keep custom attributes where they explain the work, and define them consistently across teams.
ACDFMC+1
Illustrative workspace · interactive demonstration
Inside the approach
How the model works.
Field mapping is deterministic. Validation checks required fields, dates and relationship keys. Unknown or conflicting values are flagged for review rather than silently filled.
Methodology and evaluation01Source records
02Mapped fields
03Connected projects
Before you move forward
Make the mapping explicit.
| Review | What to look for |
|---|---|
| Identity | Use a stable source key to distinguish an update from a new record. Names alone can collide. |
| Dates | Agree on timezone and date meaning. A target date and a forecast completion date are separate fields. |
| Status | Document how source statuses map to your working view. Preserve exceptions instead of forcing every state into done or not done. |
| Conflicts | Choose an owner for duplicate or conflicting values and retain enough source context to resolve them. |
Questions & answers
A few useful answers.
Can I use custom fields?
The model is designed around meaningful project attributes. Discuss your required fields and mapping with the team during setup; this public table demonstrates a specific fictional schema.
What does Export do?
It downloads a CSV of the demonstration rows in the current view. It does not export private customer records or connect to a third-party account.
How should missing data be handled?
Keep it visible as unknown. A missing owner, effort estimate or deadline should prompt review rather than be replaced with a value that appears confirmed.
Ship what you promised.
Bring the plan, the work and the next decision together.