Workforce systems, in plain English
A workforce decision rarely stays in one system. These articles explain why that happens, how composerID gives the decision a common reference, and the technical ideas we are exploring as the product develops.
Triage decides. Composer publishes. Your systems execute.
Triage decides how the work should be done. composerID publishes a reference for that decision. The systems you already use carry out the work.
Why one workforce decision needs one reference
One request can appear in several systems, each with its own number. The problem is knowing they all came from the same decision.
Your workforce stack is bigger than the VMS
A contractor, a permanent hire and a statement of work end up in completely different systems. That is why the decision has to come first.
What composerID actually sends to other systems
Triage knows the reasoning behind a decision. The systems downstream do not need it. Share the reference, not the whole decision.
What an integration actually does
Authentication, data format and an address: the three things every integration has to get right, in normal language.
How composerID fits with Triage today
composerID ships as part of Triage. What that means today, why the boundary is drawn there, and what we are not claiming yet.
Where a workforce request really starts
Requests start in messages and tickets, not workforce systems. Triage asks its questions there, before a form decides the shape.
Research: system of engagement
Systems of record, engagement, intelligence and action: a deep-research report on where each term comes from and what it should mean.
Why customer-specific fields make integrations hard
Two companies on the same platform can require completely different information. Why the customer's own configuration is the real gate.
Why integrations need protection against duplicates
Sometimes a computer sends the same request twice. A publishing service should notice. Engineers call this idempotency.
What we learned mapping Beeline’s API
We mapped Beeline's published specifications to see how a decision reference could be carried. Mapping is not the same as live.
How systems tell you what happened next
Some systems send updates, some need to be checked, some need configuring. The options for knowing what happened after a publish.
How we keep vendor integration research up to date
Vendor documentation moves and changes. How we keep integration research traceable to primary sources, and what re-checking found.
How to prove an API really works
If we cannot write an acceptance test for a technical claim, we should be careful about making it publicly. The rule and the tests.
How a publishing API should authenticate
Who is calling, what may they do, and for how long: the authentication model we propose, explained before the OAuth vocabulary.