Assembled Workforce Management

Customers who sync the GET /v0/people endpoint into their data warehouses have no way to recover missed syncs, as the endpoint only returns the current state of the roster with no date filtering. Two solutions have been requested: An as_of date parameter on the existing People endpoint (e.g. GET /v0/people?as_of=2026-06-13) to retrieve a point-in-time snapshot A dedicated change-log/history endpoint for the People API that returns roster changes over a specified time range, similar to the agent-state edit-history endpoint This would allow customers to backfill missed syncs and maintain accurate historical workforce data in their internal systems.

When a workflow relies on an API call to enrich customer context (e.g., fetching account flags or user segments), failures today are silent. The workflow continues as if no data was returned, which can cause incorrect or harmful actions for customers who should be excluded from normal flows entirely. Request: Ability to configure custom alerts when an API or enrichment call in a workflow fail, for example, a Slack notification, email, or in-platform alertm so teams can catch failures immediately and prevent miscategorized customers from receiving the wrong experience. Use case: We havespecific customer segments that require completely different handling. If the enrichment API silently fails and those flags don't propagate, standard workflows fire on exempt customers, creating compliance and operational risk.

Ability to pull metrics on schedule change requests via the API: Who requested the change timestamp of change if the request was approved/denied who approved/denied the request Denial reason

When a person is deactivated via the API using DELETE /v0/people/:id (with hard=false), there is currently no way to restore them via the API. Restoration is only possible through the Assembled UI, which breaks fully automated people management workflows. Solution would be to add a dedicated public API endpoint to restore a deactivated person.

Currently, only Working Hours rules are accessible via the Assembled public API (GET /v0/scheduling_rules/working_hours). Shift, Event, and Productive Work rules can only be managed through the UI, creating a gap for teams that need programmatic control over their scheduling configuration. The request is to extend the public API to expose the remaining scheduling rule types, following the existing endpoint pattern: GET /v0/scheduling_rules/shift GET /v0/scheduling_rules/event GET /v0/scheduling_rules/productive_work Exposing all scheduling rule types via the API would unlock fully programmatic management of scheduling configuration, enabling customers to automate setup, maintain consistency across environments, and integrate Assembled into their existing infrastructure workflows. This is particularly valuable for technical and enterprise users who manage configurations as code or rely on API-driven tooling rather than manual UI changes.

API Update: add a feature where a link is attached on each segment that will lead us directly to the chat, call or email that the agent was working on. This allows the WFM to easily investigate the reason for the aux or the lack thereof and also track the avail time where the agents are not working on any particular ticket.

Currently, POST /v0/requirements only supports uploading a single requirement object per request. Attempts to send a bulk body shaped like { "requirements": [...] } return a 400 error. This is inconsistent with POST /v0/forecasts, which supports bulk uploads of up to ~200 interval objects per request, enabling high-throughput workflows. The impact: customers uploading large requirement grids are forced into a one-request-per-object pattern, significantly increasing runtime due to HTTP overhead — even with parallelisation and rate limiting.Currently, POST /v0/requirements only supports uploading a single requirement object per request. Attempts to send a bulk body shaped like { "requirements": [...] } return a 400 error. This is inconsistent with POST /v0/forecasts, which supports bulk uploads of up to ~200 interval objects per request, enabling high-throughput workflows. The impact: customers uploading large requirement grids are forced into a one-request-per-object pattern, significantly increasing runtime due to HTTP overhead — even with parallelisation and rate limiting.

User Story: I should be able to see and copy the UUID for each site and team directly in the Settings UI so that I can configure or update API integrations without needing to make additional API calls or involve an engineer. Details: Currently, site and team UUIDs are not visible anywhere in the Assembled UI. Customers using the API (e.g., the /v0/reports/adherence endpoint) must make separate GET /v0/sites and GET /v0/teams API calls just to discover the IDs required to construct their requests. For non-technical users managing API polling jobs (such as adding new sites to an integration), this creates unnecessary reliance on engineers to retrieve these IDs. Displaying the UUID id for each site and team alongside its name in the Settings UI (Settings → Sites and Settings → Teams), even as a simple copyable field, would make it significantly easier for customers to self-serve.

Currently the Reports API exports adherence data at a minimum of 1-hour intervals. We'd like the option to pull adherence at 30-minute granularity. Why this matters: Many workforce management operations schedule and measure agents in 30-minute blocks. When adherence is only available at 1-hour grain. We schedule at the half hour and would like to understand our net effective agents after you adherence is considered. Current workaround: We use raw agent activity and agent state data to calculate adherence at custom grains in our data warehouse. This works but writing and maintaining this code is prohibitively more work than being able to export the data direclty. Requested change: Add a grain or interval parameter to the Reports API that accepts 30m in addition to the current 1h minimum. The underlying data is already calculated second-by-second — this would be an aggregation change on the export, not a calculation change.