Copilot

When Copilot is included in your purchase, it adds a workspace for the team building on Nudova, not for shoppers or day-to-day store staff: give it a requirement and it drafts OpenProject work packages, with a human approval step before anything reaches OpenProject. See Copilot for what the domain does and why it’s scoped this way.

Open Copilot (admin.your-domain.com/dashboard/copilot).

Who actually uses this screen

Unless your team is running engineering work through OpenProject alongside Nudova, Copilot has nothing for you — it isn’t a merchant help desk or a storefront assistant. See the caution on Copilot before enabling it for a purely retail team.

Generate tickets

The root Copilot screen is a canvas: type or paste a requirement (attachments welcome — screenshots, docs), pick the OpenProject project and ticket type, and generate. Progress streams in live rather than blocking on one long request, moving through a fixed sequence:

pending → ingesting → processing → (needs_clarification or awaiting_duplicate_decision, if either applies) → review → publishing → completed

Copilot may pause mid-run to ask a clarifying question, or flag that a similar ticket already exists and ask you to decide — you answer inline and generation resumes. What comes out is a set of draft tickets (title, type, estimate, priority, acceptance criteria, test stubs) you can edit before anything is sent anywhere.

Nothing reaches OpenProject without approval

Generated tickets sit as drafts until someone approves them. There is no setting that publishes straight to OpenProject unattended.

Threads

Copilot → Threads lists past and in-progress generation runs — reopen one to see the conversation, retry a run that stalled or failed, or pick up a clarification it’s still waiting on.

Project knowledge

Copilot → Knowledge shows, per connected OpenProject project, whether its memory is synced and when it last ran — this is what lets Copilot ground a draft ticket in your project’s real conventions and history instead of generic boilerplate. Sync re-indexes a project on demand.

Usage and impact

Two separate read-only dashboards:

• Copilot → Usage — token/request usage against your plan, for your company and (if visible to you) the platform as a whole. Sync embeddings here is a manual trigger for the same indexing Knowledge shows the status of.
• Copilot → Impact — over a rolling window: tickets pushed to OpenProject, the acceptance rate, and how many were accepted, rejected, closed, still in progress, or the average days from draft to close. This is the “is this actually saving anyone time” view.

Settings

Copilot → Settings holds the OpenProject connection and the default ticket-type mapping (which OpenProject type a Feature/Bug/Epic draft maps to). Each Copilot agent role runs its own model — a slow or verbose model on any one role, not just drafting, can stall a whole generation run; that’s also why a run can time out without any of your prompts being at fault.

Permissions

copilot.use covers the canvas and threads; copilot.manage_settings covers Knowledge and Settings; copilot.view_usage and copilot.view_impact gate their respective dashboards separately, so you can hand someone visibility into impact numbers without also handing them the OpenProject connection. Grant these through Users & roles.

Related: Copilot · Entitlements · Users & roles.