Support¶
Open Support in the navigation to browse Support Workspaces grouped by Project. Access requires the enabled Support capability and the support or admin Keycloak role, including the Project's access restrictions.
Workspaces¶
The workspace list shows configured JIRA connection keys and the latest synchronization time across those connections, alongside knowledge document and synchronized ticket counts.
Administrators create, edit, archive and delete workspaces from project.html. The form contains the workspace's key, name and description. Saved keys are immutable. Each workspace has its own knowledge, tickets, connections and cases. Deleting a workspace removes its imported evidence and conversations; it does not delete JIRA tickets or previously published comments.
The workspace Assistant resolves your question and conversational references before selecting evidence. It can look up literal ticket/case keys and identifiers in processed knowledge documents, semantically search and reason over synchronized tickets, accepted Support Case evidence and processed Knowledge, or read collection metadata and totals. Only evidence assessed as relevant is passed to the answer. Answers cite supplied evidence and state whether coverage is focused, complete collection metadata, partial, or insufficient. Requests to scan every document's contents or perform explicit multi-hop graph traversal are reported as unsupported; ordinary reasoning about Knowledge relationships is supported; selecting a document keeps retrieval restricted to that document. A collection list can stop at the retrieval budget; an authoritative unfiltered total does not require loading every item.
You can ask “Find tickets assigned to Peter Kissa”, “Find similar Support Cases”, or “Explain the recovery procedure from Knowledge”. Assignment filters use the synchronized JIRA ticket assignee; a Case uses its linked ticket's assignment. Names mentioned in comments do not establish assignment. Case content search uses accepted source snapshots, excluding private conversations and unaccepted snapshots. Preparing Cases can still provide identity and assignment metadata. Ask “What can you help me with?” for a capability explanation without searching business evidence. After upgrading from a version that omitted assignees, run the normal connection synchronization to populate those fields and refresh ticket search.
Workspace tabs are Support Cases, Tickets, Knowledge and Connections. Cases is the default. The AI button in the page header opens the standard AI Assistant modal when Contextual Assistant is enabled for the Project. It uses the same chat, Markdown, prompt controls and retrieved-artifact links as other workspaces. Sessions are private to the acting user. Read-only MCP retrieval includes this workspace’s cases, synchronized tickets and processed knowledge evidence. When requested, it also uses published Organization evidence allowed by Available to AI Assistant in Tenant settings. Questions about the tenant’s people or certifications select Organization evidence; explicit local-only requests exclude it. Project knowledge and other workspaces remain excluded. Reviewed changes remain in the Support Case workflow.
The search panel returns up to ten results, combining semantic matches with supporting Knowledge passages. Numeric Score badges apply to semantic matches. Knowledge match identifies a passage retrieved through Knowledge relationships without a similarity score. Loose, good and strong filter scored semantic matches; Knowledge matches can remain at any threshold. Changing the threshold reruns the search and can change the ten returned results. Press Escape in the search field or click its transparent × button to clear the query and results. Click a result, or focus its details and press Enter or Space, to open the document or JIRA ticket.
Support Cases and Tickets show the newest items first by default. Use the ordering button beside either tab to cycle through Newest → Oldest → Key. Clicking it opens that tab and orders the filtered list. Each tab remembers its order in the page URL, including after refresh. Date ordering uses case creation time or the ticket’s creation time in JIRA. Tickets without a creation timestamp appear after dated tickets; key ordering uses natural numeric order (for example, HELP-2 before HELP-10).
Tabs use the same layout as Epic: text and status filters sit in a toolbar below the tabs, with actions on the right and the list underneath. Support Cases can be filtered by preparing, active, deferred or closed; closed includes both closure outcomes. Knowledge can be filtered by pending, processing, ready or failed; and Connections by active or inactive. Tickets offers the actual JIRA statuses present in the imported tickets, displayed in lowercase. Choose * to clear the status filter. Status and text filters combine, retain the selected sort order, and remain selected during background refreshes while the page is open.
Tickets and Support Cases load 15 rows at a time. Use Load more tickets or Load more Support Cases at the bottom of the list to append the next page. Text and status filters apply to the entire workspace before paging, and sorting stays consistent across pages. Changing a filter or sort order restarts the list; background refreshes retain those selections and keep loaded rows visible until replacement data arrives. Ticket status filters and the ticket count describe the whole workspace, not just the loaded page.
Knowledge documents¶
When Knowledge Graph is enabled, focused Knowledge questions also retrieve the original passages supporting matching concepts and assertions. You do not need to request graph traversal explicitly. For example, a name found in an isolated table cell can be supplemented by the table that establishes the person’s role. Every passage still passes relevance assessment and remains within the selected source scope.
Support Knowledge includes configuration facts and operational experience: symptoms, diagnoses, investigation steps, known errors, workarounds, recovery actions and their documented outcomes. Historical resolutions retain their applicable environment and supporting evidence; a similar incident does not automatically have the same cause.
The Knowledge tab contains this Support Workspace's documents and uploaded files. Knowledge documents in the workspace summary shows their count. Knowledge from other workspaces or from the parent Project is not included.
Choose New to open Review knowledge. Enter a Title and Content, then choose Approve and save to knowledge. To revise a text document, choose Open knowledge document on its card, edit the content, and approve the save. You can also select a text document under Update existing document; replacing its content requires confirmation. Uploaded files cannot be edited as text—add the revised file instead.
Saving a new or edited text document starts background processing. The card shows progress and any failure; use Retry to resume failed processing. A document becomes available to later investigations after embeddings and all enabled processing stages complete. When Knowledge Graph is enabled, processing also extracts concepts and evidence-backed relationships. Editing is unavailable during processing, and previous content is excluded from retrieval while the replacement is being prepared. Existing text entries keep their current semantic indexing until edited; this change does not reprocess them automatically.
Support Knowledge Base is the central document for Assistant suggestions explicitly accepted in this Support Workspace. Each approval appends a titled section once, retaining the entry's reviewer, case, ticket and evidence provenance. Its card appears first and shows the accepted-entry count; Open knowledge document displays the combined text read-only. Uploaded files and manually created documents remain separate. Cards share a fixed action-column width and keep titles, format, progress and counts aligned at the top; actions wrap below the content on narrow screens.
Accepted Knowledge Base sections retain their own case, ticket, confirmations and supporting evidence through processing. Repeated titles or text do not merge their provenance. Historical combined documents without entry mappings remain readable, but their excerpt-level provenance is unavailable until the approved content goes through reviewed processing; attribution is never guessed from another section.
If older accepted suggestions still have separate cards, choose Consolidate accepted knowledge and confirm. Their reviewed content is copied into the combined document; the next new approval also includes these existing accepted entries. Only after processing succeeds do their separate cards leave the list and retrieval; historical records and references are retained. Consolidation excludes unaccepted drafts, dismissed suggestions and manually created documents. If the knowledge base is processing, a new acceptance remains approved and offers Retry creation once processing finishes. Repeating an approval or retry never adds its section twice.
Knowledge files¶
In Knowledge, choose Add files. The dialog uses the same layout as Project Workspace: drop one or more files into the drop area or choose Open files, review Selected files, then confirm with Add files. PDF, DOCX, Excel (.xlsx), HTML, Markdown and text files are supported, with the same default limit of 20 MiB per file.
After upload, each file appears as a source card with its original format, processing status and structure counts. Files use the Project Workspace pipeline: normalized pages/sections/blocks, structural graph projection, embeddings, and—when Knowledge Graph is enabled—concept and assertion extraction. Background progress updates automatically, including knowledge extraction units. The header shows Ready when all enabled stages have completed; the completed progress bar is then hidden. Failures show error details and Retry reuses the staged content. This display does not change the existing processing or Assistant access rules.
Structure opens the same expandable document hierarchy used in Project Workspace, with locations, captured links and pagination. Knowledge opens the shared Knowledge explorer with concept search, assertion details, supporting evidence, local graph and fullscreen graph. Each Expand another hop click adds one hop without a fixed depth limit. Support knowledge inspection stays within the selected knowledge file; it has no Project-wide scope switch. Source cards show available counts for sections, blocks, concepts and assertions (and pages or spreadsheet rows where applicable); hover over a count for its meaning. Unavailable counts are omitted. Ask about this Source opens the standard AI Assistant modal with local retrieval restricted to that file; use Reset to start a new workspace-wide conversation. Delete removes the file's structure, knowledge and search projections; wait for processing to finish before deleting.
Expand AI reading: 259 passages · 21 uncertain for an explanation of saved AI interpretations. Uncertain includes passages that could not be confidently interpreted or classified, not missing Requirements or a Findings review queue. Structure provides source previews and Knowledge provides extracted Concepts and Assertions; neither enumerates the flagged passages or lets you mark them resolved. Ask about this Source prepares a question for you to edit and send. Ask about a specific topic and check the cited passages; questions do not clear the count. Older Sources may show AI reading details unavailable.
With knowledge extraction enabled, Refresh analysis applies the current analysis to a processed Source's saved content without another upload. It keeps the Source identity, stored structure, source embeddings and accepted knowledge provenance. The existing background processing job shows progress and failures; refresh is unavailable while processing is active. Compatible interrupted checkpoints are reused when available, but a completed analysis may require new paid AI calls. Refresh does not change the accepted knowledge text or guarantee that fewer passages remain uncertain.
The Add files dialog tracks uploads and retains unsuccessful files for retry. Completed uploads leave the selection and continue processing in the background. Original files are not retained. Files uploaded before this processing flow were stored as plain text. These cards explain that the original file must be added again; Structure remains disabled because the original layout and real counts are unavailable. Add the originals again to process structure and knowledge. Text documents and explicitly approved Assistant knowledge retain their existing editing flow.
Connections and tickets¶
Support connections require a JIRA Service Management project with customer requests. Regular Jira Software or business projects cannot be used as Service Desk connections. Validation checks the project type, and synchronization checks it again for previously activated connections. If a regular project was configured, select the correct Service Management project key and validate again; replacing a valid security token will not correct the project type.
An administrator selects Add JIRA SD in Connections to add a JIRA Service Management source. The buttons and Add/Edit dialog follow Spec Connections, with a scrollable form and Save/Cancel actions at the bottom. Each connection has a key, name, URL, JIRA project, authentication settings and an Active/Inactive status. Multiple connections are supported without requiring a Specification. Add GitHub and Add GitLab are disabled; their hover text explains that they are currently not supported.
Provider operations use the acting user's default JIRA security token in Profile, regardless of the token's name. Configure your own PAT before validating, synchronizing, fetching attachments or publishing. No shared integration credential is substituted. Cloud Basic authentication uses the existing email-and-API-token format; service account authentication requires the Cloud ID. Activation validates the source with your token. The connection row shows your credential readiness and its synchronization state.
Connection rows follow Spec Connections: the name appears above a muted details line, with Shared and token-readiness badges on the right. Click a row, press Enter/Space on its focused details, or select Edit to open the connection modal. Users without configuration permission see View and read-only settings. Validate and administrator-only Delete are in the modal footer. When editing, Validate saves the current form values first; if saving fails, validation stops and the error stays in the modal. In read-only mode, it validates the saved settings.
In Tickets, select an active connection beside Sync, then click Sync. A single active connection is selected automatically. The first successful synchronization imports the complete project; later runs resume from the saved ticket checkpoint and import only newly created tickets. Synchronization runs in the background. The connection selector narrows when the synchronization label grows, keeping the status filters accessible. Tickets are saved individually and the list refreshes while synchronization is running, including after reopening the workspace. Comment retrieval and search indexing can still take time for new tickets; tickets already imported remain available if a later step fails. Tickets show their source connection, key, summary, provider status and JIRA creation time in your local timezone. After import, the source identity is fixed. Referenced connections can be deactivated; only unused connections can be deleted. Imported shared evidence remains readable without a provider token.
Validation displays the specific JIRA error in the modal. For Cloud, use Email and API token (Basic) and store the default Profile token as <atlassian-email>:<api-token>. PAT (Bearer) is for Data Center/Server. The Cloud ID field appears and is required only when Service account authentication is selected. It is unused for Basic or PAT (Bearer). Errors distinguish token format, authentication mode, expired credentials, project permissions, missing projects and network failures. Retain the Request ID when contacting an administrator.
If comments cannot be retrieved for a ticket, synchronization imports that ticket without comments and continues. Skipped comment retrievals are recorded in the application logs. Comments from other tickets remain available.
Support Cases¶
Case rows follow the Requirements layout: the key and status badges share the header, with the case name below and Edit on the right. Click the row or focus its details and press Enter/Space to open the case; Edit opens the metadata modal.
In Tickets or the JIRA ticket modal, choose Create Support Case. The standard modal prefills the case key from the connection and ticket keys, and its name from the summary. There is one case per ticket. Existing cases offer Open Support Case. Edit case metadata from the workspace's case row.
The detail page uses the standard Project → Workspace → Case context tree. A separate Details panel shows the case name from the workspace list, ticket priority, and local creation/update times. Lifecycle actions sit beside its heading. Statuses appear as horizontal pills without adjacent labels. Hover over each pill for its category, current value and meaning: the AIKOZO investigation lifecycle, evidence preparation, evidence freshness, or the imported JIRA ticket status. The same descriptions are available to screen readers. Prepared means evidence preparation is ready, not that the case is ready to close; Current refers to the synchronized ticket evidence. A resolved JIRA ticket can still have an active AIKOZO investigation. Its tabs are AI Assistant, Evidence and Conclusion; semantic search remains on the Support Workspace page. The Assistant uses the contextual Assistant layout with a compact two-line composer and a Send button that fills its height. The conversation, retrieved artifacts and knowledge suggestions scroll within a viewport-sized area, keeping the composer visible without scrolling the page. On narrow screens, the conversation and context panes stack within the same bounded area.
Evidence shows compact version rows with preparation status, the accepted-version badge, timestamps and gap counts. Open a version by clicking its row or Open evidence to inspect its summary, expandable finding groups and gaps in a modal. Sources are grouped by document; each excerpt retains its citation and document location. Citation buttons open the shared Project Workspace evidence viewer. Accepting a version or acknowledging gaps still requires explicit confirmation.
Both evidence dialogs keep their title and footer buttons visible while only the content scrolls, with consistent spacing between the header, content and actions.
Preparation snapshots the ticket, chronological comments with authors and visibility, and supported attachments. It uses the same extraction and resource limits as Project Workspace. Unsupported formats, scanned-only PDFs and failed attachments remain visible as gaps. Review and explicitly acknowledge gaps before activating the case, or retry preparation. Evidence sources retain locations and clickable citations. They do not count as knowledge documents.
Synchronization also reads the ticket's direct inward and outward JIRA issue links. Each distinct linked ticket is retrieved once from the connected JIRA site using your default Profile token, including metadata, readable comments and attachment metadata. Links belonging to those linked tickets are not followed. Linked issues may belong to other JIRA projects, but they remain evidence of the original ticket within this Support Workspace; they do not create separate synchronized tickets or cases.
The ticket modal and evidence-version modal list Linked JIRA tickets, their relationship labels and retrieval status. Preparation gives readable linked content and supported attachments their own sources and citations, preserving the originating ticket key. Missing permissions, unavailable tickets, comment failures and failed attachments leave explicit evidence gaps without discarding the original ticket or other readable links. JIRA can hide links completely from an account; AIKOZO can list only the links JIRA returns.
Creating a Support Case refreshes its JIRA ticket before preparing the first evidence version, including when the ticket was synchronized before this feature. For an existing case, choose Refresh ticket to collect direct links and prepare a new version. Connection-wide Sync is incremental and does not revisit previously imported tickets. Existing accepted evidence stays pinned until the normal evidence acceptance rules select the new version.
JIRA Cloud REST attachment content is requested with redirect=false, returning the bytes through the connected JIRA site. Existing signed downloads from the exact hostname media-cdn.atlassian.com remain supported without forwarding JIRA credentials. HTTPS, destination validation, redirect limits and upload limits remain enforced; adding api.media.atlassian.com to the allowlist is unnecessary.
Static PNG and JPEG attachments from the original ticket or its direct links are validated and interpreted during the existing preparation job. Images must fit the configured upload limit, the 8 MiB image limit and 12 megapixels. AI extracts visible text and visual observations; the resulting excerpts preserve their ticket origin and citations. Open evidence displays the original image saved with that evidence version. Verify extracted text against the image. Unreadable content, interpretation limitations and AI failures remain reviewable gaps; a validated image remains available even if AI extraction fails. Retry preparation rebuilds saved ticket evidence; Refresh ticket retrieves current JIRA links and comments first.
A case moves from Preparing to Active. Choose Defer to set the investigation aside; its status becomes Deferred. Resume returns it to Active. Deferral keeps Assistant interaction, conclusion editing and evidence refresh available. It does not schedule a reminder or automatic resumption, or change the JIRA status or SLA.
Close case remains available before a conclusion has been reviewed. Its dialog offers two explicit closure outcomes:
- Reviewed conclusion: inspect the saved conclusion, then close. Accepted current evidence and a reviewed conclusion are required. If these are missing, the dialog explains the prerequisite and offers Review conclusion to open the Conclusion tab.
- Investigation discontinued: end the investigation without a reviewed conclusion and enter a brief reason. The reason is required and retained with the acting user and time in case history.
Both outcomes display Closed. Details shows the closure outcome and, for a discontinued investigation, its reason. Older discontinued cases without a reason display No reason recorded. Closure retains the investigation and does not assert that the incident was resolved, change the JIRA ticket, or publish a comment. Choose Reopen case before further investigation or editing; reopening refreshes evidence. JIRA status remains independent and never closes an AIKOZO case automatically.
Shared investigation and refresh¶
The case Assistant conversation is shared. Turns retain authorship and their accepted evidence version; only one turn runs at a time. Retrieval includes case evidence plus relevant knowledge and historical tickets from the same workspace. It excludes other workspaces and other artifact domains.
The Case Assistant resolves intent before retrieval, including follow-ups and corrections. It searches the accepted evidence snapshot pinned to the turn and selects only the needed supplementary knowledge or tickets. It may also search published Organization evidence made available to the Support Case Assistant, but only when the detected intent visibly requests Organization, company, tenant, published, or shared evidence. Primary evidence has its own allocation. Earlier citations and graph relationships are candidates, not proof of relevance: each excerpt must pass assessment for the current question. Knowledge and Organization excerpts retain their source attribution, and obsolete supplementary versions are rejected. Answers report focused or insufficient evidence coverage; complete scans and collection counts are unsupported. Clarification happens before retrieval. User-reported details can still support an explicitly reviewed knowledge proposal when retrieved evidence is absent.
Connection synchronization does not revisit imported tickets. To retrieve changes to the ticket linked to a Support Case, choose Refresh ticket in the case Details panel. The refresh uses the acting user's token and, for Preparing, Active and Deferred cases, automatically prepares new evidence when the ticket changed. Accepted evidence remains available during preparation. New gaps require acknowledgment. Accepting updated evidence invalidates the conclusion's previous review. Closed cases update their imported ticket details but retain their evidence until reopened. A retry uses the retrying user's token.
The Case Assistant uses the standard contextual Assistant message layout: copy either a prompt or a response, hover over a message (or focus its copy control) to see its local timestamp, and read the detected intent below each new prompt after the response completes. Responses support Markdown headings, emphasis, lists, tables with an expanded preview, code, quotes and links. Enter sends; Shift+Enter inserts a newline. The animated drafting dots remain visible while the turn is queued or running, and sending is disabled until it finishes.
The right pane shows one card per ticket or knowledge item. The case ticket’s snapshots, comments and attachments are grouped under its ticket card; individual fragments and citation buttons are omitted from this pane. Open an artifact card to inspect the ticket or knowledge item. Evidence references in the response still open the detailed cited information. The source pane describes the latest completed response while another turn is running. Evidence gaps and uncertainties appear in the conversation; conclusion review and publication remain on the Conclusion tab. Earlier messages without intent metadata remain readable and copyable.
Conclusions and publication¶
Save an editable conclusion draft, then explicitly review it against the accepted evidence. Closing with the Reviewed conclusion outcome requires that review and current evidence; publication is optional. A reviewed conclusion in a case closed with that outcome can still be published.
Preview publication shows the destination ticket, exact comment text and visibility. Internal is preselected; choose Customer-visible only when appropriate. Approval queues a JIRA Service Management comment using your default PAT. The publication record retains the AIKOZO actor and JIRA receipt. Ticket status and assignment remain managed in JIRA.
Publication requests are deduplicated. If the outcome is unknown, inspect JIRA and reconcile the receipt—or explicitly confirm that no comment was published—before sending again. An uncertain result is never automatically resent. AIKOZO's own published conclusions are excluded from independent supporting evidence.
AI knowledge candidates are saved to Knowledge only after explicit review and approval. GitHub/GitLab sources, OCR of scanned PDFs, standalone image documents in the CMDB and scheduled synchronization are outside this version. PNG/JPEG attachments in Support Case evidence are supported.
Knowledge suggestions¶
In a Support Case's AI Assistant, ask, for example, “Capture this resolution as a knowledge proposal.” The Assistant uses the accepted case evidence and relevant conversation to resolve “this”. If essential details are missing, it asks for them. A supported operational resolution is eligible even when it contains no configuration-management facts.
For example, a GitLab pipeline incident with disk-full errors can yield a proposal recording the actual remediation task, who performed it, the affected environment and the documented outcome. User confirmations remain attributed; the person who approves the entry is recorded separately from the remediation actor. The Assistant must not invent commands or infer success solely from ticket closure.
The Assistant may propose zero, one or several reusable knowledge entries as the conversation develops. The shared Knowledge suggestions queue persists across turns. Review suggestion shows the full entry and its cited evidence or user-provided details. Edit optionally changes its English title and content; Add to knowledge base explicitly approves that entry and starts background processing, while Dismiss records the decision without saving knowledge. Created and dismissed entries remain in Reviewed suggestions. Use Open knowledge entry on a created suggestion to inspect the saved document. While processing, the suggestion remains approved and shows its progress. It becomes created when processing succeeds; a failed attempt retains the approved text and offers Retry creation without creating a duplicate. Suggestions are excluded from retrieval until approved and successfully saved. Saved entries retain case, ticket, evidence-version and reviewer provenance.
Each draft may show Duplicate probability—an AI estimate of overlap with the strongest retrieved knowledge candidate, not a statistical guarantee. Possible duplicates opens a comparison of the proposed text, candidate excerpts, individual estimates and reasons, with links to the existing entries. Retrieval checks only this Support Workspace’s knowledge. No candidates found does not prove uniqueness. A high estimate never blocks creation; the user decides. The comparison records its assessment time. After a manual edit, the estimate is marked as applying to the earlier draft, which remains inspectable in the comparison.
Ask the Assistant to revise an existing pending draft, for example “Add the names of the people who resolved this issue.” When supported by the evidence, the same candidate is updated with their names and individual actions. Explicit revision requests can also update manually edited drafts; the Assistant uses the current text and preserves unrelated edits. Unsolicited refinements cannot overwrite manual edits, and approved, created or dismissed records cannot be revised by the Assistant. A concurrent change prevents a stale revision from overwriting newer work. Stale actions require refresh. Repeated creation requests use the same knowledge record; an interrupted save appears as approved but unfinished and offers Retry creation.
Before revising, the Assistant resolves the candidate from recent conversation and the current queue. For example, “Create this as a Knowledge entry with steps and people involved, without the requester” can revise an identifiable pending Copilot provisioning candidate. It keeps the same candidate and includes evidenced contributors and their actions while honoring the exclusion. If several candidates fit, it asks which one. An unavailable or protected target receives its specific reason; dismissed candidates are not recreated, and publication still requires explicit approval.
When investigating another case in the same Support Workspace, ask about similar incidents or possible resolutions. The Case Assistant combines current evidence with relevant historical tickets and ready Knowledge entries, including evidence selected through knowledge relationships when enabled. It cites the historical source, explains why the resolution may apply, and identifies conditions to verify first. Pending or dismissed suggestions, incomplete processing, obsolete document versions and other workspaces are excluded. The workspace-level AI Assistant remains read-only; capture and approval take place in the Support Case workflow.
Personal Assistant prompts are available through the small ▴ glyph above the message composer or Arrow Up while editing a message. See AI Assistant prompts for reuse, favourites, retention and Profile management.
Knowledge extraction also checks evidence across sections within one file or text source. Reviewed entries combined into the Support Knowledge Base can participate together, while each supporting passage retains its own entry provenance. Similarity selects passages to check; it never establishes a relationship by itself. The source card shows cross-section checking progress, and the evidence inspector labels every contributing section. Ticket preparation is unchanged.