After building a few automations, Airtable bases tend to accumulate junk fields: "Processing status", "Sent to Slack", "Last webhook timestamp". These are operational breadcrumbs, not data you actually need to store.
Two categories of fields
Operational fields exist only to track automation state — which step fired, whether a notification was sent. Most of these can be eliminated entirely if you design your scenario correctly.
Analytical fields are what the business actually cares about: order value, client name, delivery date, outcome. These belong in Airtable permanently.
The mapping pattern
In Make, use the scenario's own data flow to carry operational state. A record ID from Airtable, piped through subsequent modules, is enough to update the right record at the end — you don't need a "scenario run ID" field in your base.
For multi-step flows where Make can't carry state (e.g. waiting for an external event), store only the minimum: a status enum field with 3-4 values, not a timestamp for every transition.
Result
Bases stay readable. When a client or team member opens the Airtable view, they see business data — not automation scaffolding.