For operations teams
Turn handoffs into records. Give each team a clear view.
Model requests, owners and suppliers in one operations app, with access shaped around responsibility rather than another spreadsheet copy.
Give the work a relational home
Start with connected tables. A shared name in two spreadsheets is not a relationship.
- Requests
- Keep status, requester, owner and deadline on one record.
- Suppliers
- Link requests to the supplier handling them instead of repeating supplier details.
- Activities
- Relate work items to their request so handoffs retain context.
Decide who sees what, before the first screen
Groups grant access per table, row, field and action. Every surface follows those rules.
- Requesters
- Grant access to requests they submitted without exposing everyone else's queue.
- Operators
- Assign groups access to the queues they actually handle.
- Costs
- Make cost fields readable only to the groups that need them.
Different jobs deserve different screens
The Data grid is the starting point. Interface ideas can be described to the assistant and built over the same authorized data.
- Triage
- A Data view grouped by request status and sorted by deadline.
- Work queue
- A task-focused interface for an operator's assigned items.
- Supplier view
- A page that collects requests linked to a supplier.
Try this as your app brief
“Create an operations app with Requests, Suppliers and Activities. Requesters see their own requests. Operators work in assigned queues. Cost fields are restricted to finance.”
This is an app design example, not a ready-made template. gtable is a work in progress and not open yet. Explore the product or other use cases.