Best Practices for Structuring Tasks and Issues

[Jack_Tranckle]

Hi Airtable community,

I’m seeking advice on the best way to structure a base that involves Tasks and Issues, which have overlapping fields but serve distinct purposes. Here’s the situation:

• Issues: These require detailed tracking and notes, including fields like changes made, follow-up steps, progress status field, open/closed field, inspection notes, and specific next actions. They are client-facing, often shared externally via reports or synced with external platforms.

• Tasks: These are broader, internal actions (e.g., conducting reviews, generating reports, collecting data) that help our team manage workflows. Tasks frequently lead to the creation of multiple Issues. Tasks need fields like progress tracking, notes, and assignees

Shared Requirements:

1. Quality Control (QC): Both Tasks and Issues require QC, and we need a single view or dashboard to easily track what requires QC across both types when they are ready.

2. Active Assignment Restriction: Only one Task or Issue should be active for an individual at any given time. We plan to automate status changes so that starting work on one automatically pauses other assignments for that individual.

3. Team Management Dashboard: In addition to QC, we aim to build a dashboard that shows all work in progress (Tasks and Issues) and tracks total time in progress for each issue/task. This will help us better manage our team’s workload and ensure efficiency.

My Questions:

• Should I combine Tasks and Issues into a single table or separate them into two?
• What are the advantages or drawbacks of each approach, considering they share many fields like Status, Assigned User, Progress, and QC?
• If separated, what’s the best way to link them (e.g., Tasks generating Issues)?
• If separating into tables, how can I create a single QC view or management dashboard dashboard that accommodates both Tasks and Issues effectively, even if they’re in separate tables?
• if keeping as one, i appreciate the dynamic filtering however due to the different fields required i would likely need to benefit from using an interface - where this does not work so well

I’d love to hear your thoughts and experiences with similar setups. How would you recommend structuring this to balance functionality, clarity, and scalability, while supporting effective team management?

Thanks in advance for your insights!

[Mike_AutomaticN]

Hey @Jack_Tranckle.!

Further information would be needed to take a better decision. You could go either way.
To avoid Links and Backlinks to the same table (as Tasks are linked to multiple Issues), and given the differences mentioned, I would probably suggest having two different tables -specially if this is the core of your system. (e.g. if we were discussing a system/base with a very wide scope, of which this is only a very small aspect, it might make sense to have it under 1 table to avoid complex architecture).

To link them, you'l have a 1:many relationship between Tasks and Issues.

You can have a Blank layout interface, showing two different views within one same interface (downside to Blank interfaces is that they cannot be accessed on Mobile).

In any case, this seems to need some more context. If you'd like to have the discussion, I'd be down for a brief call. Just ping me via Private Message.

Mike, Consultant @ Automatic Nation