Pending Mappings
Pending mappings are unmapped RFID tags that have been flagged for manual review. When a workflow detects unknown tags and is configured with deferred mapping, those tags appear here instead of being processed automatically. This gives you a chance to review, verify, and map them to the correct inventory items.
Overview
The Pending Mappings tab of the Inventory page is a review queue built around the scan group, the batch of tags a single scan event detected together. The list shows one row per scan group; opening a group takes you to its own mapping workspace where you select tags and map them.
When tags are waiting, an amber dot appears on the Inventory entry in the navigation menu and on the Pending Mappings tab, so you notice the queue without opening the tab and can see which tab the dot points at. Hover the dot to see how many tags are waiting: the number of tags still pending (not the number of groups). The dots respect the scope filter, are shown to users with View Pending Mappings, and reload each time you navigate or change the scope filter rather than on a timer.
From the Pending Mappings area you can:
- Review scan groups containing unmapped tags flagged by workflows
- Open a group to select tags and map them to inventory items, together or one at a time
- Dismiss tags that don't need mapping, and reinstate a dismissed or expired tag if you change your mind
- Purge resolved records (mapped, dismissed, or expired)
- View scan context (device, workflow, timestamp, signal data) for each tag
Permissions
| Permission | What It Allows |
|---|---|
| View Pending Mappings | See the pending mappings list and open scan groups |
| Manage Pending Mappings | Map tags, dismiss tags, reinstate tags, and purge resolved records |
How Tags Get Here
- A workflow includes a Map Unmapped Tags action with Defer Mapping enabled
- When a scan event contains tags not already in the system, those tags are added to the pending mappings queue as a group, tied together by the scan event's correlation ID
- Each pending tag stores its scan context: device, workflow, timestamp, antenna, RSSI, and read count
- The group is scoped to the scanning device's site, not the workflow that queued it. This means you only see groups scanned at sites you have access to, even if the workflow itself runs in the system scope and serves many sites at once.
Note: If an earlier action in the same workflow run already mapped a tag, for example another Map Unmapped Tags action ahead of this one, this action treats it as already mapped and skips it rather than mapping it again. A tag handled that way won't produce a duplicate pending row here.
The Pending Mappings List
Columns
| Column | Description |
|---|---|
| Scanned | When the scan event that produced this group occurred |
| Device | The device that scanned the tags, with its device group beneath |
| Workflow | The workflow that queued the group for deferred mapping |
| Tags | A count chip per status present in the group: pending, mapped, dismissed, expired |
| Scope | Access scope (shown when multiple scopes are active) |
Search and Filters
Search by EPC, device name, or workflow name. Use the Status filter to show groups containing tags of a particular status (the list defaults to groups with Pending tags, so resolved history stays out of your day-to-day view), and the Queued Date filter to narrow by when the group arrived.
Mapping Tags
Click a group's row, or choose Open from its actions menu, to open the group's mapping workspace at /pending-mappings/{correlationId}.
The workspace shows every tag in the group, pending and already resolved, in one table with its status, scan details (antenna, RSSI, read count), and, once mapped, a link to the inventory item it became.
To map tags:
- Select the pending tags you want to map using the checkboxes (or select all)
- Choose the target Item. Items offered are the group's site catalog plus shared (system-scope) items; only items with automatic instance IDs can be mapped this way
- Choose a Location. Only locations in the group's own site are offered, mapping cannot place items into a different site than where they were scanned, and only locations that allow inventory are shown
- Choose a Transaction Type for the placement (defaults to "ADD"). Close-out types are not available here because mapping places an item into a location, which is the opposite of a close-out
- Fill in any custom fields shown for the selected item. Fields marked required must be filled before you can map
- Save
Each selected tag becomes its own new inventory item, tagged with that EPC and placed at the chosen location. If you select a partial set of tags, Tagnet asks whether you want to continue mapping the rest of the group or return to the list, so you can split a batch across different items and locations in one visit.
Note: Because mapping creates a new inventory item, the created instance takes the location's access scope. Since locations are restricted to the group's own site, every instance created from a group stays in that site.
Dismissing Tags
If a tag doesn't need to be mapped (e.g., it's a known environmental tag or test tag), dismiss it from the group's workspace:
- Select the tags and click Dismiss selected, or
- Use Dismiss all pending from a group's row menu on the list to dismiss every pending tag in that group in one step, regardless of how many there are
Dismissed tags remain visible with a "Dismissed" status until purged.
Reinstating a Tag
A dismissed or expired tag isn't final. In the group's workspace, click the reinstate icon on any Dismissed or Expired row to return it to Pending, where it becomes selectable for mapping again. Reinstate is refused if the same EPC has since become pending in a newer scan group, or has already been mapped elsewhere. Like any other status, a tag stays reinstatable until its record is purged.
Purging Resolved Records
Click Purge resolved on the list header to permanently delete all Mapped, Dismissed, and Expired records. This button is visible to anyone with Manage Pending Mappings permission. A confirmation dialog is shown before deletion.
Purging only removes the pending mapping records. It does not affect any inventory items that were created during mapping, and once a record is purged it can no longer be reinstated.
Best Practices
- Review pending mappings regularly: Groups waiting in the queue represent items that aren't being tracked yet.
- Work group by group: Opening a scan group gives you full scan context (which tags were detected together, by which device, and when) so you can map an entire batch efficiently.
- Fill required custom fields as you map: The workspace enforces required fields before it lets you save, so batches don't create instances that are missing data you need downstream.
- Dismiss intentionally: Only dismiss tags you've verified don't need tracking. If you dismiss the wrong tag, reinstate it rather than re-scanning.
- Purge periodically: Clean up resolved records to keep the queue focused on actionable items. Remember that purging is final; reinstate anything you might still need first.