Skip to main content

Deliverable Tags: Group and Filter a Report by Package

Label individual deliverables with client-facing tags so a shared report can be grouped into named packages and filtered down to just what a client wants to see.

Deliverable tags are short, client-facing labels you attach to individual deliverables on a report — for example Social Media Package May 2026. Once a deliverable is tagged, the tag shows up as a chip on the report, and anyone viewing the shared report can filter or group by it.

Tags solve two everyday reporting problems:

  • Grouping deliverables into named packages. If a single sale bundles several posts, stories, and newsletters together, one tag per package lets you keep everything in one report while still showing the client each package on its own.

  • Letting a client slice a big report down to what they care about. On a report with dozens of deliverables, a viewer can filter to a single tag and see only that slice — no separate report needed.

Where you’ll see tags on a report

Deliverable tags appear on the shared report (the link you send a client, or the public share URL). There are three places they show up.

Tag chips on each deliverable card

Every deliverable that has tags shows them as small chips on its card. Clicking a chip filters the report down to that tag, so a client can start from any card and drill into its package.

Deliverable cards on a shared report, each showing its tag chips

The Tags filter

Near the top of the report, next to the existing Filter, Group, and Sort controls, is a Tags control that lists every tag used in the report. Select one or more tags to narrow the report to just those deliverables — the filter is multi-select, so a client can combine packages. Deselect the tags (or click an active chip again) to widen the report back out.

The Tags filter narrowing a report down to a single package

Group by: Deliverable tag

Open the Group control and choose Deliverable tag to bucket the report by tag. Each tag becomes its own section with its own header, and any deliverables that don’t have a tag collect in an Untagged group, which always sorts last.

A report grouped by deliverable tag, with an Untagged section last

Filtering, sorting, and grouping stack together: the Tags filter narrows the set first, then the report sorts and groups within whatever is left.

A note on how grouping and filtering behave for the client: grouping and sorting choices a viewer makes are just for their session. They’re a quick way to look at the report from a different angle, and they reset when the page is reloaded — the client never changes your saved report.

Who this is for

Deliverable tags touch two groups of people:

  • Anyone reviewing or sharing a report. You don’t have to do anything special — if the deliverables on a report are tagged, the chips, the Tags filter, and the Group-by-tag option appear automatically on the shared report. You (and your clients) can filter and group from there.

  • Teams automating InfluenceKit through the MCP integration. If you build reports programmatically — for example, syncing completed deliverables from Airtable — you set tags at the same time you add the deliverable. This is how a “package” field in your source system becomes a client-facing tag on the report.

Setting tags today (through the MCP integration)

Right now, tags are set through InfluenceKit’s MCP integration — the same interface used to add deliverables, attach descriptions, and create reports programmatically. Both the add_deliverable and update_deliverable tools accept a tags argument.

tags accepts either an array of strings or a single comma‑separated string, so it fits whatever your automation produces:

{  "tool": "add_deliverable",  "arguments": {    "event_id": 4321,    "urls": "https://www.instagram.com/p/abcd1234/",    "tags": ["Social Media Package May 2026"]  }}

{  "tool": "add_deliverable",  "arguments": {    "event_id": 4321,    "urls": "https://www.instagram.com/p/abcd1234/",    "tags": "Social Media Package May 2026, Spring Launch"  }}

To change the tags on a deliverable that already exists, use update_deliverable with the same tags argument. Setting tags on an update replaces the deliverable’s entire set of tags, so the record in your source system stays the single source of truth:

{  "tool": "update_deliverable",  "arguments": {    "deliverable_id": 9001,    "tags": ["Social Media Package May 2026", "Spring Launch"]  }}

  • Pass an empty array ("tags": []) to clear all tags from a deliverable.

  • Omit tags entirely to leave the existing tags untouched while you change something else (a title, a description, manual stats, and so on).

If you’re wiring this into an Airtable + MCP workflow (one tag per package within a sale, passed over when you send the completed deliverable), the full walkthrough — connecting your automation, creating reports, and mapping fields to tags — lives in InfluenceKit’s MCP automation guide. Reach out to support and we’ll point you to it.

Coming soon: tagging from the app

In‑app tag editing — adding and changing tags right on a deliverable inside InfluenceKit, without the MCP integration — is on the roadmap. Until it ships, tags are set through the MCP integration as described above.

Turning this on for your account

Deliverable tags are available on every account — there’s nothing to turn on. Tag a deliverable and the chips, the Tags filter, and Group‑by‑tag option start showing up on your shared reports automatically; reports with no tagged deliverables render exactly as before.

Did this answer your question?