The queue every write to your ERP passes through.
The console is the screen a buyer, planner, or engineer actually works in. Every action Polymr wants to take shows up here as a row that fits that person's role. Below the queue sits the audit log: a permanent record that lets you take any approved row and rebuild, field by field, the documents it came from.
One row per pending write.
This is the queue a buyer or planner opens at the start of their shift. Each row is something Polymr wants to do: an RFQ to send, an award to lock in, a PO to issue, a cost variance to acknowledge. Nothing here is hypothetical. Every row shows who can approve it, a link back to the source document Polymr read, and two actions: approve, or send back for review.
Approvals queue · all roles
5 pending · scoped to (plant=NW1, territory=US-W) · oldest 38m
Take any approved row apart. Field by field.
The console does not store screenshots; it stores the trail behind every number. Every cell on an approved row links back to the document that produced it. The view below shows that for a sent PO: four cells, each one tracing straight down to the source it came from.
A buyer never sees rows a buyer cannot act on.
The filter that hides rows from the wrong person is not just a line of code in the app. It is enforced inside the database, comparing the row's plant, role, and territory against the person's permissions the moment the queue loads. The same rule guards the audit log, so a compliance query that runs outside the console honors the same permissions. There is no back door to the data that could disagree with what you see in the queue.
The role names on rows and in the audit log are your own. Polymr does not keep a separate user list in production; it syncs role membership from your identity provider and uses your role names everywhere. Two operators sharing a workstation can still be told apart at quarter-end because the row records the role the action was taken under, not just a user id.
Twelve writes, one click, one reason when something is off.
When the queue is full of writes that belong together, the operator gets a bulk-approve button. A day of RFQs going to the same vendor. A tray of POs against the same purchase plan. A batch of EDI 855 acknowledgements going to the same customer. Bulk approve runs each row through the rules one more time. Any row that has fallen out of policy since entering the queue asks the operator for a reason before the rest are approved together in a single audit entry.
The reason is structured. A free-text field, an optional pick from a list your team maintains, and a marker for whether the rules should learn from this exception going forward. If the same kind of operator has already attached the same reason to the same kind of exception before, the next time around it does not ask again. The audit row still records the full history, so the shortcut is traceable.