# Admin fields are real forms: inside FormWork's team fields Canonical: https://useformwork.com/blog/admin-fields-are-real-forms-why-formworks-metafields-are-so-powerful Updated: 2026-10-09 Most tools treat internal admin fields as notes and status tags. FormWork's team fields use the full form engine, with automations and repeatable groups. *Updated 9 October 2026: metafields are now called team fields. They live on the entry rather than in a linked entry, and their changes show in the entry's history.* Most form builders have some version of "internal fields." Usually that means a couple of extras: - status - notes - maybe an owner or tag Useful, but limited. For demanding applications, internal operations are not simple. They need structure, branching, dependencies, automation, and auditability. So in FormWork, we made a deliberate decision: admin fields are not a side panel feature. They are built with the same form engine as the main form. ## The usual problem with internal fields In many platforms, internal fields are bolted on as a lightweight metadata layer that only supports basic key/value storage. That is fine until operations scale. Then teams want things like: - repeatable internal checklists - conditional admin-only sections - automations triggered by internal changes - calculated internal values derived from both user answers and admin inputs - clean audit history of internal changes At that point, simple key/value metadata becomes a bottleneck. ## How FormWork does it Every FormWork form can have team fields: internal fields your team fills in on each entry, which respondents never see. You design them in the same builder as the form itself, with the same field types, settings, default values, logic and validation, plus a **Team member** field for things like who an entry is assigned to. Team field values live on the entry, next to the respondent's answers. (In the API they are still called `metafields`.) Instead of "special little admin fields", you get an internal model that uses the same schema engine as the rest of the platform. Statuses, owners, due dates and approvals now have their own home in the form's process and stages. Team fields hold everything else your team needs to record. ## What this gives you in practice ### 1) Real schema power for internal operations Your internal layer can use structured fields instead of flat notes: - grouped internal sections - repeatable structures - validation and conditional behaviour - references in automations If your operational process is complex, your admin model can match it. ### 2) Internal automations are first-class Team field changes can start automations, and so can buttons in the team fields panel. That means your ops team can drive automation from the admin side, not just react to submissions. Example patterns: - **Quote approvals**: admin sets an internal discount, an automation recalculates totals and generates updated output - **Escalation routing**: admin changes priority, an automation reassigns the entry and notifies the right people - **Compliance gates**: admin marks a check as complete, an automation stamps timestamps and moves the entry to the next stage Automations can read both user answers and team fields, and update either. ### 3) Public and internal data can work together cleanly Because team fields sit on the same entry as the answers, conditions, emails and automations can bridge external input and internal processing. You can keep respondent-facing data separate from sensitive internal state while still automating across both. Respondents never see team fields, and FormWork won't publish a form if something respondents see uses one. That separation is useful for regulated, multi-stage, or review-heavy processes. Keep in mind that team fields are hidden from respondents, not from your team. ### 4) Versioned with the form Team fields are part of the form's draft. You change them alongside the rest of the form, and they go live when you publish. When you publish, existing entries move to the new team fields. The publish review tells you how many entries will be converted, and values that no longer fit, such as text in a field that is now a number, are cleared and recorded in the entry's history. In short: one place to change your internal model, and no older entries stuck on an outdated version of it. ### 5) Audit trail for internal changes Team field changes are recorded in the entry's history, so you can see who changed what and when, alongside answer corrections, stage moves and automation runs. And because internal fields often get edited a lot, changes made close together are grouped into one item, so you get traceability without a history line for every tiny change. ## Why this matters for agencies If you deliver systems for clients, internal process is where projects become sticky. Anyone can deliver a public intake form. Fewer teams can deliver the operational back half: review, triage, approvals, escalation, correction, handoff. Team fields, together with stages and automations, let you build that internal layer properly inside the same platform. That means: - less custom admin tooling per client - faster delivery for complex process-heavy projects - clearer boundaries between customer-facing and internal data - better long-term maintainability It is a practical way to deliver "enterprise-like" behaviour without building a custom app from scratch every time. ## Why this matters for advanced no-code builders If you have used many no-code tools, you have probably seen this pattern: - public form works - internal process grows - platform cannot model internal complexity - automation becomes brittle - you bolt on extra tools and scripts FormWork's team fields and automations are designed to avoid that trap. You can evolve internal operations with the same discipline you apply to the public form, instead of treating internal state as an afterthought. ## Examples of use cases ### Underwriting and risk review - internal scoring blocks - reviewer decisions - escalation status - automated downstream actions based on admin decisions ### Service delivery - internal task packs per submission - repeatable service line items - fulfilment details and SLA dates - automations for handoff and notifications ### Agency client operations - internal QA fields - approval checkpoints - billing/fulfilment flags - ops notes that are structured, not free-form chaos ### Support and case handling - triage categories - assignment and escalation details - resolution classification - internal-only timelines and outcome fields ## Others usually stop short here. We don't. Most tools stop at status + notes because the full-schema approach is harder. You need to support: - the same field engine for internal fields as for the form - references across answers and team fields - automation triggers on internal updates - moving existing entries to new internal fields when the form changes - revision behaviour that is both traceable and sane We chose a model that scales for demanding applications. FormWork's team fields give you that internal system without building a separate admin app.