Most engagement teams hit the same wall eventually. A land referencing category for a compulsory purchase order, a consultation stage that doesn't match the software's fixed pipeline, a tag for 'raised at a drop-in session' rather than by email. The system wasn't built with that field, and adding it isn't an option.
Custom tagging and field mapping solve that. In a stakeholder relationship management (SRM) system, it means you can add the categories, tags and data fields your own engagement work actually needs, at the stakeholder, interaction or project level, rather than working around whatever fields the vendor shipped with.
What custom tagging and field mapping mean in practice
Tagging labels an interaction, issue or stakeholder by theme, so 'noise complaint', 'objection to route', or 'requested Welsh translation' become searchable, reportable categories rather than free text buried in a notes field. Field mapping goes a level deeper: it lets you define what a record actually captures, adding fields for land parcel reference, funding stream, consultation stage or whatever your programme tracks, and deciding which are required, optional or scored.
Tractivity, the UK stakeholder relationship management platform, builds this in as configuration rather than customisation. You select which data fields to use, create custom fields across multiple modules, and set up your own categorisations and themed issues, no development ticket required and no forced workflow to work around.
Why generic CRM fields fall short here
A standard CRM's fields are built around a sales pipeline: contact, deal stage, revenue, close date. Stakeholder work runs on a different set of concepts entirely, interest, influence, sentiment, affiliation, land interest, statutory role, and none of them map cleanly onto 'opportunity'. As we've covered in what actually separates stakeholder engagement software from CRM, stakeholder grouping, interaction-level sentiment and issue tracking all have to be built into a CRM with custom objects, custom fields and reports rather than switched on, and someone then owns that build through every platform upgrade.
What configurable tagging and fields let you do
Once the data model matches your engagement work instead of a sales pipeline, a few things become possible that a fixed schema won't allow:
-
Consistent reporting on your own categories. Because tags and custom fields are structured data, not free text, they roll up into filters and reports automatically, land parcel reference, funding stream or consultation stage included, without a manual reconciliation exercise at reporting time.
-
One taxonomy across every module. The same custom fields and tags apply to stakeholders, interactions, issues and events, so a theme tagged on an email and the same theme tagged on a survey response show up together.
-
Attribute-based stakeholder mapping. Tractivity's stakeholder mapping module extends this into scoring: alongside standard attributes like interest, influence, sentiment and relationship, you can define and score any custom attribute your project needs, with no limit on the number of attributes per map.
-
Change without losing history. Fields and tags can be added or adjusted as a programme evolves, without the audit trail against existing records breaking.
Tagging at scale, a live example
This isn't a theoretical benefit on a long-running programme. Across the Hinkley Point C and Sizewell C consultation programmes, EDF Energy has logged and tagged around 30,000 stakeholder issues in Tractivity, maintaining a 100% response rate throughout. At that volume, an untagged issue is effectively an invisible one. Custom tagging by issue type, theme and status is what keeps 30,000 individual items reportable rather than buried.
What to check when you're evaluating this
A vendor demo can make almost any system look configurable. Before you rely on it, check:
-
Which modules the custom fields actually reach. A tool that lets you customise the stakeholder record but not issues, surveys or events will still leave you exporting to a spreadsheet somewhere.
-
Whether reports and dashboards use your custom fields, not just the standard ones. A custom field that only ever shows on the record screen isn't doing the reporting job you need it for.
-
Who can make the changes. If every new tag or field needs a request to the vendor's support desk, it isn't really configurable, it's customisation with a queue attached.
-
Whether there's a practical limit. Ask directly whether there's a cap on the number of custom fields, tags or attributes, and get the answer in writing rather than inferring it from the demo.
-
What happens to existing records when a field changes. Renaming or retiring a field shouldn't silently break the audit trail on records that already used it.
Book a personalised demo with the team and we'll show you exactly how your tags, fields and categories would look inside Tractivity.
Frequently asked questions
No. Configuration is designed to be handled by an administrator on your team, selecting which data fields to use and creating custom fields and categorisations directly in the platform, without a development request.
Within Tractivity's stakeholder mapping module there's no limit on the number of attributes per map. For fields and tags elsewhere in the platform, ask your vendor for a written answer rather than assuming from a demo, since this varies between systems.
In Tractivity, they're structured data from the point you create them, so they're available to the 150+ pre-built reports and configurable dashboards, not confined to the record screen.
A tag labels something, an interaction, issue or stakeholder, with a category such as a theme or sentiment. A custom field captures a specific piece of data against a record, such as a land parcel reference or funding stream. Most SRM work uses both together.
