General workspace template
A shaped but unopinionated starting point for tracking something that does not look like any of the other thirteen.

- Linked tables, not tabs
- Relationship columns join the rows instead of copying them into three places.
- Sample rows on arrival
- Every table opens with data in it, so the dashboards draw before yours does.
- Your own data, imported
- CSV, XLSX, a connected Google Sheet, or an email you forward straight in.
- Reshaped by describing it
- Say what is different and Ferra changes the structure and the rows together.
What is a general workspace template?
Some processes don't look like anything in a template library, and this one is Ferra's answer: Items, People and Activity: the things you track, the people responsible for them, and what has happened to each one. Three linked tables, deliberately unopinionated, with sample rows loaded and a status dashboard on top, for anything the other thirteen templates don't name.
Almost everything worth tracking is the same three tables underneath: the things, the people responsible for them, and what has happened to them. This template gives you exactly that shape with nothing domain-specific bolted on, so the first thing you do is rename it. Say what Items really are, tickets, applications, assets, complaints, and Ferra renames the table, the links pointing at it and the dashboard built on top in one move.
Three tables, no domain attached
Items gives every tracked thing a row: a name, a status, a priority, a due date, free-text notes, and an owner pointing at a row in People. The sample: Replace loading bay lights, In progress, High, due 6 Mar, quote approved and waiting on parts. People holds each person who owns items, with role, team, email and an Open items formula counting what they currently carry. Activity logs one row per update against an item: the date, a type such as Decision, what actually happened, and who it was by. That last table is what keeps a status field from going amnesiac.
Why generic beats blank
Tickets. Applications. Assets, complaints, maintenance requests, grant submissions. Underneath, every one is the same skeleton: a thing with a status and an owner, a person who owns things, and a history of what changed and when. The nouns differ; the shape doesn't. Start from the shape and the relationships, the formula and the dashboard already work: what's left is the one part only you can do, which is saying what these rows are.
Renaming is the first step, not a chore
Rename it before you do anything else. Tell Ferra what Items really are. Items becomes Maintenance requests, Owner becomes Assigned engineer everywhere it appears, and the table, the relationship columns pointing at it and the dashboard built on top all rename in a single move. No hunting down stray mentions of the old name, and the sample rows travel with the change, so nothing sits half-renamed.
The dashboard it ships with
Status overview splits open, in progress, done and overdue by owner and by priority, and it earns its keep before you've decided what any of this is called. It keeps earning it after: what's overdue and who owns it, how the work splits across the team right now: answered without anyone building a view first.
Questions it answers
“What's overdue, and who owns it” is the daily one. “What changed this week” reads Activity and comes back as a list of things that happened, not a diff. The sleeper is “which items have had no activity in a month”: the question that surfaces work that has quietly stopped moving. A status column alone can't answer it, because a stale row and an active one look identical until you check their history.
When to use it, and when not to
Reach for this when your process is genuinely your own and none of the other thirteen templates names what you do. Skip it when a closer one exists: if what you track is deals, candidates or shipments, start from that template and describe the differences instead. Adding a table to a working workspace is a sentence. Reconciling two sets of sample data is an afternoon.
Getting your data in
Whatever list you run now imports directly: CSV, XLSX, a connected Google Sheet, even an email forwarded in and read into a table. People goes first, so items have someone to point at. Items next. Then rename everything into your own words: doing it after the import is fine, because the change applies to the structure and the rows together.
You may also like
Browse all templatesFrequently asked questions
The questions people ask before starting from the General workspace template.
Anything the other thirteen do not name: tickets, assets, requests, complaints, submissions. It is the shape almost all of them share: a thing, an owner, and a history.
No, and you are meant not to. Say what Items really are and Ferra renames the table, the relationship columns pointing at it and the dashboard together.
Use the closer one if it exists and describe the differences. Starting generic is only better when nothing in the library names what you track.
Yes, on the free plan with no credit card, and the sample items, people and updates are already in the tables.
Start from the shape, then rename it to whatever you actually track.
Tickets, applications, assets, complaints: whatever the row really is, one sentence renames the table and everything pointing at it.
Use template
Rename it before you fill it
Say what an item really is, a ticket, an application, an asset, and the table, everything linking to it and the dashboard rename together.
Describe a changeThree tables is the shape underneath most things
The thing, the person responsible for it, and what has happened to it. Everything domain-specific is what you add on the second day.
How relationship columns workWhatever you already track, imported
A CSV, an XLSX, a connected Google Sheet, a forwarded email or your GitHub issues all land in the table you just renamed.
Ways your data gets in







