Ticketing Integration Module¶
Questions or comments?
Post them as a comment on the tracking issue -- requires a GitHub account with access to this repo.
Novaworks PRD · v2 · Status: AI-DRAFT¶
⚠ AI-DRAFT — Human Review Required
This document was generated by Claude from a product brief provided by the CTO. It has not been reviewed by a PM or engineering lead. Content should be treated as a structured starting point, not an approved specification. Assign a named reviewer before circulating to engineering teams. Source doc kept atreference/ticket-integrations.mdfor durability.
| Version | Date | Author | Change Summary |
|---|---|---|---|
| 1 | 2026-07-01 | AI-generated (Claude) from CTO brief | Initial draft |
| 2 | 2026-07-01 | Eswar Vandanapu | Reviewed and revised |
Overview¶
The Ticketing Integration Module is the human intervention layer for Novaworks' constellation of HR agents. Its singular purpose is to ensure that when agents cannot complete work — whether due to a capability gap, an explicit user request, or a technical failure — that work lands somewhere actionable rather than disappearing.
This module is intentionally minimal. It is a proxy and a router, not a case management system. The design philosophy is deliberate: mid-market customers who have no other ticketing mechanism get a barely-sufficient fallback; enterprise customers get a flexible extension point to route tickets into their existing systems. Novaworks does not compete with ServiceNow HRSD Case and Knowledge Management or Atlassian Jira Service Management. This module is designed to make that boundary unmistakably clear.
NOTE: The scope of "technical failure" triggering ticket creation includes failures during agent orchestration and failures at the individual functional agents are both in scope, or only one.
Technical Note: Functional/Special agents communicate the failures back to the Super Agent / HR Concierge and only the super agent module is responsible for the ticket creation. If this assumption doesn't hold, we need to have an extended discussion.
Strategic Fit¶
This module supports both active company priorities:
Sidecar Strategy (Enterprise): Enterprise customers operate complex HR stacks. When Novaworks agents hit a wall, the fallback cannot be a dead end — it must land in the customer's existing workflow tooling. The extension point architecture (Script-based hooks) lets customers route into HRSD, Jira, or any custom destination without Novaworks owning that complexity. This keeps Novaworks genuinely additive rather than competitive.
Mid-Market / Design Partner Motion (Ateko and beyond): Mid-market customers who adopt Novaworks as a system of record often do not have a mature ticketing environment. The insourced ticketing tier provides a minimal safety net — enough to catch agent failures and human-escalation requests without requiring a full ITSM investment as a prerequisite to adopting Novaworks.
Ticket Creation Triggers¶
Three conditions generate a ticket in this module:
- Agent capability gap — A user request cannot be fulfilled by any available agent. The request is not dropped; it is converted to a ticket automatically.
- Explicit user request — A user or HR professional explicitly asks to create a ticket (e.g., "open a request for this"). This is a first-class interaction, not a workaround.
- Technical execution failure — An error occurs during agent execution (tool failure, orchestration error, timeout). Rather than returning a raw error, the module converts the failure state into a ticket so a human can investigate and resolve.
NOTE: Ticket body should include execution trace / error context when triggered by a technical failure. Also, if a ticket is created due to the agent capability gap, or explicit user request, request text along with any additional comments should be passed on to the ticket creation.
Ticketing Modes¶
Insourced Ticketing (Mid-Market Default)¶
When no external ticketing destination is configured, Novaworks activates its own scoped ticketing app on the ServiceNow Now Platform.
Characteristics:
- Scoped ServiceNow application — isolated from customer's broader ServiceNow instance configuration, and provides additional security for any sensitive data.
- Deliberately limited feature set; no SLA management, no routing rules, no complex workflows, beyond the simple assignment rules to be configured using the ServiceNow native mechanisms.
- Exists to prevent dropped work, not to serve as a full case management solution
- Fulfillers (HR staff resolving tickets) are directed to the Core ServiceNow UI — the Novaworks portal provides no fulfiller workspace.
- This is a deliberate product decision: keeping the fulfiller experience underdeveloped reinforces the ceiling on insourced ticketing and avoids scope creep into HRSD territory
Employee-facing (Portal UI):
- Employees can view their own pending and recently created tickets within the Novaworks portal
- View is read-only: status, reference number, creation timestamp, brief description, along with nudge, comment, reopen capabilities.
NOTE: Despite the limitations imposed on the fullfillers, we want to ensure enough satisfaction for employee facing functionality.
Fulfiller-facing:
- Core ServiceNow UI only
- No Novaworks portal fulfiller view — this is a deliberate capability gap, not a roadmap item
Open Question: Do we want to show the tickets in the Novaworks Workspace instead, though limit the UI to be a simple list, unlike the CKM Workspace. Does showing the tickets in a workspace, signal an intent to become a case management solution in the future?
Outsourced Ticketing (Enterprise / Hook-Configured)¶
When a customer configures an external ticketing destination, the module routes ticket creation through a customer-defined Script extension point on the ServiceNow platform.
Characteristics:
- Customer configures a Script extension point that runs a different scripts based on the trigger conditions.
- Missing Agent
- Missing Agent Capability
- Orchestration failure
- Agent Failure
- Explicit Request
- The script receives the ticket payload and can apply any routing, enrichment, or transformation logic the customer requires
- Supported destinations include (but are not limited to): ServiceNow HRSD Case Management, Atlassian Jira, custom internal systems
- Novaworks has no visibility into what happens to the ticket after the hook fires — this is by design
Employee-facing (Portal UI):
- At the moment of ticket creation, the portal surfaces the external reference number returned by the hook
- This reference number is displayed to the employee and stored in Novaworks for audit purposes
- No ongoing status tracking. Novaworks does not poll, query, or display further status updates for outsourced tickets
- Employees who need status updates are directed to the external system directly
Pre-integrated HRSD CKM¶
In the event our ticketing module detects the presence of CKM in the ServiceNow instance, it should default to using the HRSD CKM automatically instead of using our inbuilt mechanism for triggers unrelated to failures.
Open question: How intelligent we should be when opening a CKM ticket? Should we try to align the COEs to agents, or just create everything into "Ask HR" category?
Out of Scope¶
The following are explicitly not part of this module, now or in future iterations:
- SLA tracking, escalation rules, or ticket prioritization logic — use ServiceNow HRSD
- A fulfiller portal or ticket management UI within Novaworks
- Status polling or webhook ingestion from external ticketing systems
- Outbound notifications to employees on ticket status changes (outsourced mode)
- Multi-destination routing (a single ticket going to more than one external system)
- Ticket templates or custom field schemas beyond a standard minimal payload
Integration Points¶
| Surface | Behavior |
|---|---|
| Nova HR Concierge (Portal) | Employee ticket list (insourced); reference number display (outsourced) |
| Novamobile | TBD — mobile ticket creation confirmation and reference display recommended but not scoped |
| Nova MCP Gateway / A2A Proxy | Agent failure state triggers ticket creation via internal API — no direct end-user surface |
| ServiceNow Core UI | Fulfiller workspace for insourced tickets |
| External Systems (HRSD, Jira, etc.) | Reachable via customer-configured Script extension point; Novaworks makes no assumptions about destination |
| Nova Constellation of Agents | Agents call the ticketing module when capability gap or failure is detected; module is opaque to the agent — agent receives a confirmation + reference only |
Work Breakdown Structure (WBS)¶
Delivery model: Novaworks operates as a Feature Factory on a monthly release cadence. The WBS below is decomposed into features, each sized to be independently shippable within a single monthly increment. Features are sequenced so that every release delivers standalone customer value and later features build on earlier foundations. Sequencing is a recommendation, not a hard dependency chain except where noted.
NOTE: This section is entirely auto generated using AI and kept for reference only.
Feature Roadmap (at a glance)¶
| # | Feature | Release | Serves | Depends On |
|---|---|---|---|---|
| F1 | Ticket Creation Core & Payload Contract | M1 | Both tiers | — |
| F2 | Insourced Ticketing — Scoped ServiceNow App | M2 | Mid-market | F1 |
| F3 | Employee-Facing Portal UI (Insourced) | M3 | Mid-market | F2 |
| F4 | Agent & Orchestration Failure Integration | M3 | Both tiers | F1 |
| F5 | Outsourced Ticketing — Script Extension Point | M4 | Enterprise | F1 |
| F6 | Outsourced Reference Surfacing & Audit Store | M5 | Enterprise | F5 |
| F7 | Pre-integrated HRSD CKM Auto-Detection & Routing | M6 | Enterprise | F1, F5 |
F1 — Ticket Creation Core & Payload Contract (M1)¶
The internal ticket-creation API and canonical payload every downstream mode consumes. Foundation for all other features.
- 1.1 Trigger detection framework
- 1.1.1 Agent capability gap trigger (request unfulfillable by any agent)
- 1.1.2 Explicit user/HR request trigger ("open a request for this")
- 1.1.3 Technical execution failure trigger (tool failure, orchestration error, timeout)
- 1.2 Canonical ticket payload schema
- 1.2.1 Standard minimal fields (requester, timestamp, description, trigger type, reference)
- 1.2.2 Execution trace / error context capture for technical-failure tickets
- 1.2.3 Original request text + additional comments capture for capability-gap / explicit-request tickets
- 1.3 Internal ticket-creation API (single entry point; mode-agnostic)
- 1.3.1 API contract + versioning
- 1.3.2 Confirmation + reference-number return to caller
- 1.4 Mode-resolution logic (route to insourced vs. outsourced vs. CKM based on configuration/detection — stub destinations delivered by later features)
⚠ Blocking open item (resolve before F1 build): Confirm the Technical Note assumption — only the Super Agent / HR Concierge creates tickets; functional/special agents report failures upward. If false, F1 trigger surface and F4 scope expand.
F2 — Insourced Ticketing: Scoped ServiceNow App (M2)¶
The mid-market default fallback destination.
- 2.1 Scoped ServiceNow application provisioning (isolated from customer's broader instance)
- 2.2 Ticket record model within the scoped app
- 2.3 Native ServiceNow assignment rules (simple assignment only — no SLA, routing, or workflow logic)
- 2.4 Data isolation & sensitive-data handling controls
- 2.5 Fulfiller path → direct to Core ServiceNow UI (explicitly no Novaworks fulfiller workspace)
F3 — Employee-Facing Portal UI, Insourced (M3)¶
Read-first employee experience in the Nova HR Concierge portal. Deliberately rich enough to satisfy employees despite fulfiller-side minimalism.
- 3.1 Ticket list view (own pending + recently created tickets)
- 3.2 Ticket detail (read-only): status, reference number, creation timestamp, brief description
- 3.3 Employee interaction capabilities
- 3.3.1 Nudge
- 3.3.2 Comment
- 3.3.3 Reopen
- 3.4 Novamobile confirmation & reference display (recommended; scope TBD — carry as stretch/spike)
Open question to resolve in F3 design: Surface tickets in the Novaworks Workspace (simple list, unlike CKM Workspace) vs. portal-only? Assess whether a workspace view signals future case-management intent.
F4 — Agent & Orchestration Failure Integration (M3)¶
Wires the Nova Constellation into F1 so failures become tickets. Can ship in parallel with F3.
- 4.1 MCP Gateway / A2A Proxy → ticket-creation API integration
- 4.2 Failure-state → payload mapping (capture execution trace per 1.2.2)
- 4.3 Agent-opaque confirmation contract (agent receives confirmation + reference only)
- 4.4 Failure-scope handling for orchestration failures vs. individual functional-agent failures
⚠ Open item (resolve before F4 build): Scope of "technical failure" — orchestration-level, functional-agent-level, or both. Ties directly to the F1 blocking item.
F5 — Outsourced Ticketing: Script Extension Point (M4)¶
The enterprise Sidecar routing mechanism. Novaworks stays opaque beyond the hook.
- 5.1 ServiceNow Script extension point framework
- 5.2 Per-trigger script binding: Missing Agent · Missing Agent Capability · Orchestration Failure · Agent Failure · Explicit Request
- 5.3 Payload handoff to customer script (routing/enrichment/transformation owned by customer)
- 5.4 Destination-agnostic contract (HRSD Case Mgmt, Jira, custom — no Novaworks assumptions)
- 5.5 Post-hook boundary — no visibility/tracking after hook fires (by design)
F6 — Outsourced Reference Surfacing & Audit Store (M5)¶
Closes the employee-facing loop for outsourced mode.
- 6.1 Capture external reference number returned by the hook at creation time
- 6.2 Portal display of external reference to employee
- 6.3 Audit persistence of reference in Novaworks
- 6.4 "Directed to external system" messaging (explicitly no polling/status tracking)
F7 — Pre-integrated HRSD CKM Auto-Detection & Routing (M6)¶
Smart default for instances that already run HRSD CKM.
- 7.1 CKM presence detection in the ServiceNow instance
- 7.2 Auto-default to HRSD CKM for non-failure triggers instead of the inbuilt mechanism
- 7.3 CKM ticket creation path
Open question to resolve in F7 design: CKM ticket intelligence — align COEs to agents, or file everything under "Ask HR"?
Explicitly Out of WBS Scope¶
Per the Out of Scope section, the following generate no WBS work items now or later: SLA/escalation/prioritization logic; a Novaworks fulfiller portal; status polling or webhook ingestion; outbound status-change notifications (outsourced); multi-destination routing; ticket templates or custom field schemas beyond the minimal payload.