[HaloPSA] Add an action (note / email / reply / internal note / time entry / status change) to an existing ticket. REQUIRED: ticketId, hiddenFromUser (true = agent-only/private; false = visible to end-user/customer), an outcome, AND a body given as EITHER note OR noteHtml — one of the two, never both. Use note for a plain-text body and noteHtml for a body that contains HTML or markup. Do not send both: Halo does not merge them, and HTML in both leaves unrendered HTML in the action body. The outcome (the action TYPE) is mandatory — supply outcomeId (preferred — enumerate with halo_list_outcomes) OR the outcome name string (e.g. "Private Note", "Public Note", "Email", "Time Entry"). Halo rejects an action with no outcome ("An Outcome must be selected"). For common cases prefer the purpose-built tools, which set the right outcome for you: halo_add_internal_note (private note), halo_send_email_reply (email), halo_log_time (time entry), halo_change_ticket_status_with_note (status change). Set sendEmail=true to dispatch an outbound email; both emailTo AND emailSubject are then required (Halo will not synthesise a safe subject). Set timeTaken to log work hours. Set newStatus/newAgent/newTeam to mutate the ticket as part of this action. When newStatus/newAgent/newPriority is set, the ticket is re-read before and after the action (3 API calls instead of 1) and a mutation the ticket type's rules override surfaces as an error naming the field — the action itself (the note, any time entry, and any outbound email) is still created in that case, so do NOT re-send the call. If the confirming read-back CALL itself fails, the result is reported as an error of type write_unverified rather than a success: the write may well have landed, so re-read the ticket instead of retrying — the action, its note and any email already exist, and a re-send would duplicate them. Use extraFieldsJson for any Halo Action field not exposed as a named parameter (an outcome supplied there, e.g. {"outcome_id":5}, also satisfies the requirement).

[HaloPSA] Add an emoji reaction to a ticket action. Wraps POST /api/Actions/reaction. Useful for AI agents that want to acknowledge customer messages without posting a full reply. Halo's ActionReaction schema keys the reaction by (ticket_id, action_number) — NOT the global action id. DISCOVERY LIMITATION: Halo's Actions list endpoints (used by halo_list_ticket_actions / halo_list_actions) do NOT expose `action_number` in their response schema, so the caller must already know the per-ticket sequence number — typically from a Halo webhook payload, a previously-captured ticket UI link, or out-of-band knowledge. The 200 OK response from this endpoint has no body; the tool returns {"success":true} on success.

[HaloPSA] Add a private/internal note to a ticket — hidden from the end user/customer. Sugar over halo_add_action with hiddenfromuser=true and outcome=Private Note. Use halo_add_action for fully-custom action types.

[HaloPSA] Change the status of up to 50 tickets in one call, with per-ticket read-back verification. This is the ACTION path (outcome 'Status Change' + new_status): the supported route for workflow-governed ticket types, where a plain record update (halo_bulk_ticket_update with status_id) is accepted and then overridden by the ticket type's rules. Each ticket gets its own status-change action carrying its own note, or sharedNote when a per-ticket note is absent. After the writes every ticket is re-read and counted as successful ONLY when it verifiably holds the new status; per-ticket outcomes report verified / reverted / unverifiable / failed. Creates one audit-trail action per ticket. Note: makes one API call per ticket plus two list calls for verification.

[HaloPSA] Change a ticket's status and record an audit-trail note. Sugar over halo_add_action with new_status + note + outcome=Status Change. The ticket is re-read before and after the action (3 API calls instead of 1), and a status the ticket type's rules override surfaces as an error naming status_id instead of a false success; the note (and any outbound email) is still created in that case, so do NOT re-send the call. If the confirming read-back CALL itself fails, the result is reported as an error of type write_unverified rather than a success: the status change may well have landed, so re-read the ticket instead of retrying — the note and any email already exist, and a re-send would duplicate them. Use halo_update_ticket for status-only changes without an audit note.

[HaloPSA] Create a draft ticket or action. Drafts are saved but not yet submitted or visible to end users. Use this to prepare ticket content before finalising. Provide draft details as a JSON object. Returns the created draft with its assigned ID.

[HaloPSA] Create a new helpdesk ticket. Requires at minimum summary, details, and clientId (use halo_list_clients). Returns the created ticket with its assigned ID. WORKFLOW-BACKED TYPES: for a ticket type backed by a workflow (e.g. a Change Request), pass ticketTypeId TOGETHER with the type's workflow_id (via extraFieldsJson) and any mandatory customFieldsJson in the SAME call — Halo rejects the create if the type's required fields are missing. TARGET DATE: set the type's "Target Date & Time" via targetDate (+ targetDateTimezone); that field (FOppTargetDate) does NOT bind through customfields. `details` is stored as HTML; any <![CDATA[...]]> wrapper is unwrapped automatically.

[HaloPSA] Delete a ticket action (note, email, or time entry). This permanently removes the action from the ticket. Use with caution — this cannot be undone. Requires BOTH the ticket ID and action ID — use halo_list_actions to find IDs and verify the action with halo_get_action before deleting.

[HaloPSA] Retrieve full details for a single action (note, email, or time entry). Requires BOTH the ticket ID and action ID — use halo_list_actions or halo_list_ticket_actions to find valid IDs for both.

[HaloPSA] Retrieve a single ticket by numeric ID. Returns full ticket details including summary, status, priority, assigned agent, client, and action history. Requires a valid ticket ID — use halo_search_tickets or halo_list_tickets to find IDs.

[HaloPSA] List ticket actions (notes, emails, time entries) with optional filters. Returns action summaries including ID, note content, agent, and timestamps. Use this for escalation analysis, audit trails, or reviewing ticket activity across multiple tickets. NOTE: Halo's /api/Actions endpoint does NOT support page-based pagination — only a max-count limit. To page across large result sets, narrow with date ranges or filters instead.

[HaloPSA] Fetch all actions for a single ticket in one call. Faster than halo_list_actions when you already know the ticket ID and want the full activity history. Use halo_list_actions for date-range or cross-ticket queries.

[HaloPSA] List all available ticket types with ticket counts. Returns type IDs and names needed for creating tickets or filtering. Use this to discover valid ticket type IDs before calling halo_create_ticket.

[HaloPSA] List tickets with optional filters. Returns paginated ticket summaries including ID, summary, status, priority, client, and assigned agent. Use this to browse tickets or narrow down by status, client, agent, or priority before fetching full details with halo_get_ticket.

[HaloPSA] Log work time on a ticket. Sugar over halo_add_action with outcome=Time Entry (the canonical Halo default outcome name for time logs). Time is logged in hours (decimal, e.g. 1.5 = 1h30m). Set chargeable=false for non-billable work. Time entries are private by default.

[HaloPSA] Manager approval/rejection of a ticket action (typically a time entry). Wraps POST /api/Actions/Review which takes an Actions[] body. Sets `actreviewed=true` and maps `approved` to `timesheet_approval_status` (1=approved, 2=rejected). Use `timesheetApprovalStatusOverride` if your tenant uses different status integer values. Relevant for MSPs using Halo's timesheet approval workflow.

[HaloPSA] Full-text search across ticket summaries, details, and action notes. Returns matching tickets ranked by relevance. Use this when you need to find tickets by keyword, error message, or description rather than browsing by filters. Supports date range and client filtering to narrow results.

[HaloPSA] Send an outbound email reply on a ticket. Sugar over halo_add_action with outcome=Email, sendemail=true, hiddenfromuser=false. The reply is visible to the end user/customer. For private/internal notes use halo_add_internal_note instead.

[HaloPSA] Update an existing action. Halo has no PUT for actions — upserts go through POST /api/Actions with the action ID populated. Provide actionId and ticketId plus the fields you want to change. NOTE: this tool does NOT perform a read-merge-write — it sends only the fields you supply. How Halo's upsert handles omitted fields depends on the field and your Halo configuration; some fields may be left untouched while others may revert to defaults. To guarantee a value, set it explicitly. Use extraFieldsJson for Halo Action fields not exposed as a named parameter.

[HaloPSA] Update an existing ticket's fields such as status, assignment, priority, or custom fields, with best-effort read-back verification: after the write the ticket is re-read, and a value Halo accepted but then overrode (for example a ticket type's Status After Tech Update rule, an allowed-status list, or a status freeze) surfaces as an error naming the field instead of a false success — retrying after that error will not change the outcome. When the submitted fields cannot be compared on the read-back (for example custom fields), Halo's raw response is returned unchanged, exactly as on a verified success. A separate case: when the ticket ends up holding a value that is neither what you submitted nor what it held before, the result is an error of type write_unverified rather than a success — if Halo's own save response echoed your value the write DID land and something changed it afterwards (a concurrent edit, where a retry may well stick), and if there is no such echo nothing can be decided either way; re-read the ticket to see the stored values and do not re-send automatically. Only a value Halo normalized AT WRITE TIME — its save response already carrying the stored value — is still returned as a success, and only when the pre-write read succeeded: without the earlier value, a column Halo normalized at write time and one Halo never changed look identical, so that case is reported as write_unverified too. Separately again, when the confirming read-back CALL itself fails, the result is reported as an error of type write_unverified rather than a success: Halo accepted the write and it may well have landed, so re-read the ticket before deciding — do not retry automatically (a re-send simply repeats the same field values and creates no note or email). This modifies data visible to helpdesk staff. Requires a valid ticket ID — use halo_search_tickets or halo_list_tickets to find IDs. Note: makes 3 API calls (read, write, verify).

[HaloPSA] Submit a vote on a ticket. Used for ticket voting/polling workflows where agents or users can vote on tickets. Provide the vote details as a JSON object including the ticket ID and vote value. Returns the vote result.

[HaloPSA] Create a new client (customer organization) record. This creates data visible to helpdesk staff. Returns the created client with its assigned ID. The JSON should include at minimum a name. Follow up with halo_get_client to verify creation. Use halo_list_sites to associate sites after creation.

[HaloPSA] Retrieve full details for a single client by numeric ID. Returns client info including associated sites, contracts, and users. Requires a valid client ID — use halo_list_clients or halo_search_clients to find IDs.

[HaloPSA] List all clients (customer organizations) with pagination. Returns client name, ID, and basic details. Use this to discover valid client IDs for filtering tickets, assets, contracts, and other client-scoped data.

[HaloPSA] List end users (contacts), optionally filtered by client. Returns user details including name, email, and contact info. Use this to find user IDs for ticket creation or to see who belongs to a client. The role filter takes a numeric user-role ID, never a role name — use halo_list_user_role to resolve a name to its ID first.

[HaloPSA] Search clients by name or reference number. Returns matching clients ranked by relevance. Use this when you know the client name but not the ID.

[HaloPSA] Update an existing client's fields such as name, contact details, or custom fields. This modifies data visible to helpdesk staff. The JSON must include the client 'id' field. Use halo_list_clients, halo_search_clients, or halo_get_client to find valid IDs and current field values.

[HaloPSA] Create a new asset (device, hardware, or software) record. This creates data visible to helpdesk staff. Returns the created asset with its assigned ID. The JSON should include at minimum a name and asset type — use halo_list_asset_types to find valid type IDs and halo_list_clients to find valid client IDs. Follow up with halo_get_asset to verify creation.

[HaloPSA] Retrieve full details for a single asset by numeric ID. Returns asset info including linked tickets, assigned users, warranty status, and custom fields. Requires a valid asset ID — use halo_list_assets or halo_search_assets to find IDs.

[HaloPSA] Retrieve the next available asset tag number from HaloPSA's auto-numbering sequence. Returns the next tag value that would be assigned to a new asset. Use this before creating assets to preview or reserve the next asset tag. No parameters required.

[HaloPSA] List change history for assets. Returns records of modifications made to assets including field changes, timestamps, and who made the change. Optionally filter by a specific asset ID. Use this for asset audit trails and change tracking.

[HaloPSA] List software discovered on assets, optionally filtered by device. Returns software names, versions, and installation details. Use this to audit installed software for a specific device or across your environment.

[HaloPSA] List software version records across assets. Returns software names with their detected versions, useful for version auditing and compliance checks. Use this to identify outdated software or track version distribution across your environment.

[HaloPSA] List all available asset types defined in HaloPSA. Returns type IDs and names needed for creating assets or filtering asset lists. Use this to discover valid asset type IDs before calling halo_create_asset or filtering halo_list_assets.

[HaloPSA] List assets (devices, hardware, software) with optional filters for client and asset type. Returns paginated asset summaries including name, type, client, and status. Use this to browse assets or narrow down before fetching full details with halo_get_asset.

[HaloPSA] List software licences assigned to devices/assets. Returns licence assignments including software name, licence key, and expiry. Optionally filter by device ID. Use this to audit licence compliance or check which licences are assigned to a specific device.

[HaloPSA] Search assets by name, serial number, or asset tag. Returns matching assets ranked by relevance. Use this when you know identifying details but not the asset ID.

[HaloPSA] Update an existing asset's fields such as status, assignment, or custom fields. This modifies data visible to helpdesk staff. The JSON must include the asset 'id' field. Use halo_list_assets, halo_search_assets, or halo_get_asset to find valid IDs and current field values.

[HaloPSA] Clear the cached agent data in HaloPSA. Use this when agent data appears stale or after bulk agent changes to force the system to refresh agent information. Returns confirmation of the cache clear operation. No parameters required.

[HaloPSA] Retrieve full details for a single agent by numeric ID. Returns agent info including skills, team membership, and current workload. Requires a valid agent ID — use halo_list_agents to find IDs.

[HaloPSA] Retrieve details for the currently authenticated agent. Returns the agent profile associated with the API credentials, including name, email, team membership, and permissions. Use this to identify which agent is making requests or to get the current agent's ID for filtering.

[HaloPSA] List helpdesk agents (technicians) with optional team and department filters. Returns agent names, IDs, and team assignments. Use this to discover valid agent IDs for ticket assignment or filtering.

[HaloPSA] List all teams defined in HaloPSA. Returns team names and IDs. Use this to discover valid team IDs for filtering agents or assigning tickets.

[HaloPSA] Search agents (technicians) by name or email. Returns matching agents ranked by relevance. Use this when you know an agent's name but not their ID. Follow up with halo_get_agent for full details.

[HaloPSA] Create a new client contract/agreement. This creates data visible to helpdesk staff and affects billing. Returns the created contract with its assigned ID. The JSON should include at minimum a name and client_id — use halo_list_clients to find valid client IDs. Follow up with halo_get_contract to verify creation.

[HaloPSA] Retrieve full details for a single contract by numeric ID, including contract lines and billing items. Returns contract info including name, type, client, dates, and line items. Requires a valid contract ID — use halo_list_contracts to find IDs.

[HaloPSA] Retrieve full details for a single supplier contract by numeric ID. Returns supplier contract info including name, supplier, dates, terms, and line items. Requires a valid supplier contract ID — use halo_list_supplier_contracts to find IDs.

[HaloPSA] List all charge rates defined in HaloPSA. Returns rate IDs, names, and hourly amounts. Use this to discover valid charge rate IDs for contract creation or billing configuration.

[HaloPSA] List contracts/agreements with optional client filter. Returns contract summaries including ID, name, client, type, and billing details. Use this to discover valid contract IDs for utilization or profitability analysis.

[HaloPSA] List invoices with optional client and date filters. Returns invoice summaries including ID, amount, date, status, and client. Use this to review billing history or find specific invoices.

[HaloPSA] List supplier contracts/agreements with optional filters and pagination. Returns supplier contract summaries including ID, name, supplier, and dates. Use this to review vendor agreements or discover supplier contract IDs for further details.

[HaloPSA] Create a new invoice. This creates a billable document visible to finance staff and clients. Returns the created invoice with its assigned ID. Provide invoice details as a JSON object — use halo_list_clients to find valid client IDs.

[HaloPSA] Generate a PDF document for an invoice. Returns the PDF generation result including a download URL or base64-encoded content. Use this to produce a printable or email-ready invoice document. Requires a valid invoice ID — use halo_list_invoices to find IDs.

[HaloPSA] Retrieve a single invoice by numeric ID. Returns full invoice details including line items, amounts, tax, status, and client. Requires a valid invoice ID — use halo_list_invoices to find IDs.

[HaloPSA] List invoice line items. If an invoice ID is provided, returns that invoice with full line details. Otherwise returns recent invoices with their lines included. Use this to review itemized charges on invoices.

[HaloPSA] List invoice payments with optional filters. Returns payment records including amount, date, method, and associated invoice. Use this to reconcile payments or check payment history.

[HaloPSA] Record a payment against an invoice. This creates a financial record visible to finance staff. Returns the created payment record. Provide payment details as a JSON object — use halo_list_invoices to find valid invoice IDs.

[HaloPSA] Update an EXISTING invoice by fetch-merge-write. This GETs the current invoice (with all its line items), overlays ONLY the fields you supply, and posts the complete merged document back — so every field you do NOT supply is PRESERVED exactly as it was. This is the safe way to edit a live billing document: HaloPSA's POST /Invoice is an upsert that DEFAULTS every omitted header field, so sending a partial payload directly would silently reset status/dates/totals; this tool re-sends the full record to avoid that. Provide invoiceId (the invoice to change) and updateJson (a JSON object of ONLY the fields to change). Header fields overwrite the fetched values. To change LINE items, include a "lines" array: a line carrying an existing line "id" (from halo_get_invoice / halo_list_invoice_lines) is overlaid onto that FULL existing line, so its other columns (department, tax, nominal codes, etc.) are preserved; a line WITHOUT an id is appended as a NEW line; existing lines you do not mention are kept unchanged. A line id that does not exist on the invoice is rejected. updateJson must NOT carry an "id" that differs from invoiceId. Caveats: (1) idempotent for updates to existing fields/lines, but each call with a NEW (id-less) line appends it again, so do not blindly retry an append. (2) HaloPSA is expected to recompute header totals/tax from the lines on save — if you change line pricing, verify the resulting invoice total. Use halo_create_invoice for a brand-new invoice.

[HaloPSA] Void an existing invoice by ID. This marks the invoice as void — it cannot be undone. Use this only when an invoice was created in error. Requires a valid invoice ID — use halo_list_invoices to find IDs.

[HaloPSA] Create a NEW knowledge base article — never pass an existing article's 'id' here (Halo's POST /api/KBArticle is an upsert, so an id turns this into an overwrite of that live article). The article body goes in 'resolution'; HaloPSA has no 'article_content' field and silently discards unknown properties, so a body sent under the wrong name produces an empty article with no error. Returns the created article with its assigned ID. Follow up with halo_get_kb_article to verify. Never aim test, dummy or placeholder payloads at a live article — create a scratch article here and experiment on that instead.

[HaloPSA] Retrieve full details for a single knowledge base article by numeric ID. Returns the complete article including title, summary ('description'), body ('resolution'), tags and metadata. Requires a valid article ID — use halo_list_kb_articles or halo_search_kb to find IDs. ALWAYS call this before halo_update_kb_article: the update is a whole-record write, so the values returned here are what you must resend to preserve them.

[HaloPSA] List knowledge base articles with pagination. Returns article summaries including ID, title, and category. Use this to browse the knowledge base or discover article IDs before fetching full content with halo_get_kb_article.

[HaloPSA] Search the knowledge base for articles matching a query. Returns matching KB articles with titles and content. Use this to find existing documentation, troubleshooting guides, or standard operating procedures before creating tickets or responding to issues.

[HaloPSA] Overwrite an existing knowledge base article. HaloPSA exposes NO partial-update (PATCH) for KB articles — the only write is a whole-record upsert (POST /api/KBArticle keyed on 'id'), so TREAT THIS AS A FULL REPLACE: call halo_get_kb_article first and resend every field you want to keep. Fields you send are written; fields you omit are not guaranteed to survive, and Halo reports nothing when it resets one. Supplying 'tags' REPLACES the article's entire tag set — include the existing tags or they are dropped. The body field is 'resolution' ('article_content' does not exist in HaloPSA). WARNING: this overwrites live documentation, StackJack keeps no backup, and there is no undo. NEVER send test, dummy or placeholder payloads at a real article ID while debugging — create a scratch article with halo_create_kb_article and experiment on that instead.

[HaloPSA] Create a new project. This creates data visible to helpdesk staff. Returns the created project with its assigned ID. The JSON should include at minimum a name and client_id — use halo_list_clients to find valid client IDs. Follow up with halo_get_project to verify creation.

[HaloPSA] Retrieve full details for a single project by numeric ID. Returns project info including tasks, milestones, budget, and team assignments. Requires a valid project ID — use halo_list_projects to find IDs.

[HaloPSA] List tickets/tasks associated with a specific project. Returns paginated ticket summaries scoped to the project, including ID, summary, status, and assigned agent. Requires a valid project ID — use halo_list_projects to find IDs.

[HaloPSA] List projects with optional client filter. Returns project summaries including ID, name, status, and client. Use this to discover valid project IDs before fetching full details with halo_get_project.

[HaloPSA] Update an existing project's fields such as name, dates, status, or budget. This modifies data visible to helpdesk staff. The JSON must include the project 'id' field. Use halo_list_projects or halo_get_project to find valid IDs and current field values.

[HaloPSA] Generate a PDF from a saved report. Returns the PDF generation result. The JSON must include the report ID and any required parameters. Use halo_list_reports to discover available report IDs and their expected parameters.

[HaloPSA] Discover the parameters/filters of a saved report so it can be run parameterized. Returns the report's full definition (GET api/Report/?includedetails=true). HaloPSA does NOT expose a dedicated parameter schema; the parameter/filter metadata lives in the returned `filters` array (each item has fieldname, data_type, data_type_group, rule types, and string/numeric rule values) plus the reporting-period fields (reportingperiod, reportingperiodstartdate, reportingperiodenddate, reportingperioddatefield). Pass the values you want as the `parameters` object to halo_run_report.

[HaloPSA] List all saved reports available in HaloPSA. Returns report IDs, names, and categories. Use this to discover valid report IDs before running reports with halo_run_report or generating PDFs with halo_create_report_pdf.

[HaloPSA] Execute a saved report by its numeric ID and return the result rows as JSON (via GET api/Report/?loadreport=true). Optionally pass a `parameters` JSON object to apply report parameters server-side (the same parameter shape halo_create_report_pdf accepts). Each property becomes a report load query parameter — HaloPSA honors reportingperiod (int), reportingperiodstartdate, reportingperiodenddate, reportingperioddatefield, client_id, and invoice_id; unrecognized keys are ignored by Halo. Use halo_get_report_parameters to discover a report's filter/period parameters, and halo_list_reports to discover report IDs.

[HaloPSA] Get full SLA definition by ID including response time targets, resolution time targets, priority-based conditions, and applicable hours. Use halo_list_slas to discover available SLA IDs first. Useful for understanding SLA breach risks identified by halo_sla_breach_alerts.

[HaloPSA] List all SLA (Service Level Agreement) definitions configured in HaloPSA. Returns SLA names, IDs, response targets, and resolution targets. Use this to understand the SLA commitments before analyzing compliance with halo_sla_compliance_dashboard.

[HaloPSA] Create a new site (physical location) record. This creates data visible to helpdesk staff. Returns the created site with its assigned ID. The JSON must include at minimum a name and client_id — use halo_list_clients to find valid client IDs. Follow up with halo_get_site to verify creation.

[HaloPSA] Retrieve full details for a single site by numeric ID. Returns site info including name, address, client association, and contact details. Requires a valid site ID — use halo_list_sites to find IDs.

[HaloPSA] List sites (physical locations), optionally filtered by client. Returns site names, IDs, addresses, and client associations. Use this to discover valid site IDs for ticket creation or to see a client's locations.

[HaloPSA] Update an existing site's fields such as name, address, or contact information. This modifies data visible to helpdesk staff. The JSON must include the site 'id' field. Use halo_list_sites or halo_get_site to find valid IDs and current field values.

[HaloPSA] Create a new client end user (contact) record. This creates data visible to helpdesk staff and potentially end users. Returns the created user with their assigned ID. Requires first name, surname, display name, client ID, and site ID — use halo_list_clients to find valid client IDs and halo_list_sites to find valid site IDs. Some Halo instances may require additional parameters such as email address or phone number. Optionally pass username to set the portal login — some Halo instance configurations require this. Use halo_create_supplier_user to create a supplier-side contact.

[HaloPSA] Retrieve full details for a single end user (contact) by numeric ID. Returns user info including name, email, phone, and associated client. Requires a valid user ID — use halo_search_users or halo_list_users to find IDs. Optionally scope to a specific client with clientId.

[HaloPSA] Search end users (contacts) by name or email. Returns matching users ranked by relevance. Use this when you know a user's name or email but not their ID. Optionally scope to a specific client. Follow up with halo_get_user for full details.

[HaloPSA] Update an existing end user's (contact's) fields such as name, email, phone, or site assignment. This modifies data visible to helpdesk staff. Requires a valid user ID — use halo_search_users or halo_list_users to find IDs.

[HaloPSA] Update preferences for an end user (contact). This modifies user-level settings such as notification preferences, portal settings, or communication options. Provide the preference details as a JSON object including the user ID. Returns the updated preferences.

[HaloPSA] Create a new timesheet entry. This records time worked by an agent against a ticket or client. Returns the created timesheet entry with its assigned ID. Provide timesheet details as a JSON object.

[HaloPSA] Retrieve timesheet entries for the currently authenticated agent. Returns the agent's own time entries including hours, tickets, and billable status. Use this for personal timesheet review without needing to know the agent ID.

[HaloPSA] Retrieve a single timesheet entry by numeric ID. Returns full timesheet details including hours, agent, client, ticket, notes, and billable status. Requires a valid timesheet ID — use halo_list_timesheets to find IDs.

[HaloPSA] List individual time entries with optional filters for agent, client, and date range. Each entry includes the ticket, client, agent, hours worked, adjusted/billable hours, and charge type. Sourced from client-attributed timesheet events (not the org-wide capacity grid), so the agent and client filters and the date range are all honored. Use this to review time logged for a specific client or agent; use halo_timesheet_summary for aggregated totals.

[HaloPSA] Retrieve values for a specific lookup list by numeric lookup ID. Returns the configured values for drop-down fields such as impact, urgency, or custom lookups. Use this when a ticket field references a lookup ID and you need to see the available options.

[HaloPSA] List all ticket categories configured in the system. Returns category IDs and names used for classifying tickets. Use this to discover valid category values before creating or filtering tickets with halo_create_ticket or halo_list_tickets.

[HaloPSA] List all currencies configured in HaloPSA. Returns currency codes, names, symbols, and exchange rates. Use this to discover valid currency options for invoices, quotations, and financial reporting across multi-currency environments.

[HaloPSA] List all action outcome types configured in the system. Returns outcome IDs and names such as 'note', 'email', and 'timeentry'. Use this to discover valid outcome values before adding actions to tickets with halo_add_action.

[HaloPSA] List all priority levels configured in the system. Returns priority IDs, names, and colour codes. Use this to discover valid priority IDs before creating or updating tickets with halo_create_ticket or halo_update_ticket.

[HaloPSA] List all ticket statuses configured in the system. Returns status IDs and names used for ticket workflow transitions. Use this to discover valid status IDs before filtering tickets with halo_list_tickets or updating tickets with halo_update_ticket.

[HaloPSA] List all tax rules configured in HaloPSA. Returns tax rule IDs, names, and conditions that determine how taxes are applied to invoices and quotations. Use this to understand the tax calculation logic for different regions or product types.

[HaloPSA] List all tax configurations defined in HaloPSA. Returns tax IDs, names, and rates. Use this to discover valid tax settings for invoices, quotations, and billing. Needed when creating or reviewing financial documents.

[HaloPSA] Create a new ticket category. The `value` parameter is the label Halo shows in the category picker; use `>` as a separator to build hierarchy up to 3 levels deep (e.g. `Email>Outlook>PST`). `categoryType` controls whether this is a regular ticket category (1, default) or a resolution category (2). Returns the created category with its assigned ID. Halo tickets have four independent category slots (`categoryid_1` through `categoryid_4`); this tool just creates the category record — assign it to a ticket via `halo_update_ticket` using the `categoryid_N` integer field. This does not include subcategory hierarchy beyond three `>`-separated levels.

[HaloPSA] Permanently delete a category record by numeric ID. This cannot be undone. Any tickets currently referencing this category via `categoryid_1`/`_2`/`_3`/`_4` may end up with a dangling category id — prefer marking the category inactive via halo_update_category ({"inactive": true}) when possible. Use halo_list_categories to find valid IDs.

[HaloPSA] Update an existing category. Provide a JSON object of fields to change. Valid keys: `value` (use `>` for hierarchy), `type_id` (1=category, 2=resolution), `priority_id`, `sla_id`, `category_group_id`, `note`, `inactive`. Example: {"value": "Email>Outlook", "priority_id": 3}. Field names must match HaloPSA API field names.

[HaloPSA] Create a new supplier/vendor record. This adds a supplier to the system for procurement and contract management. Returns the created supplier with its assigned ID. Provide supplier details as a JSON object.

[HaloPSA] Create a new supplier-side user (contact) attached to an existing supplier. Posts to api/Users with the Halo UI-style supplier user payload (isuserdetails=true, embedded supplier object with lookupdisplay). Use halo_list_suppliers / halo_get_supplier to find a valid supplierId and the matching supplierName. Returns the created supplier user with their assigned ID.

[HaloPSA] Retrieve a single supplier by numeric ID. Returns full supplier details including name, address, contact information, and linked contracts. Requires a valid supplier ID — use halo_list_suppliers to find IDs.

[HaloPSA] List suppliers/vendors with optional filters. Returns supplier summaries including ID, name, contact details, and account status. Use this to browse suppliers or find valid supplier IDs for purchase orders and contracts.

[HaloPSA] Append NEW line items to an existing quotation (e.g. bulk quote-import workflows). Provide the quotation id plus the new lines — the tool stamps the parent link ('qhid') onto each and forces INSERT semantics by dropping any line-level 'id' you pass, so an existing line is never overwritten (the id drop also covers the advanced flat-array form). To modify existing lines instead, use halo_update_quotation_lines. HOW THE WRITE WORKS: HaloPSA has no working quote-line endpoint (POST /Quotation/Lines answers 200 and appends nothing), so the tool reads the quote, appends your new lines after the ones already there (which is what puts them at the END of the quote — HaloPSA derives each line's sort order from the order of the set it is given), and re-sends the COMPLETE line set through the quote upsert — every existing line is carried through verbatim, because that write replaces the quote's whole line collection. It reads the quotation before and after the write and fails loudly when the read-back shows no new lines at all, or fewer new lines than you submitted; HaloPSA's 200 on its own is not proof that a line was added. Where the read-back cannot settle the append either way — a read-back carrying no usable line ids to compare, or MORE new lines than you submitted (HaloPSA may have expanded a bundled line, or another writer may have appended between the two reads) — the reply comes back as {"verification":"skipped","reason":...,"halo":<Halo's response>} with the reason naming which of those it was: re-read the quote with halo_get_quotation and count its lines. Never retry a failed append automatically — the lines that did land would be appended a second time. Because the write REPLACES the quote's whole line collection with the set read a moment earlier, a line ADDED by someone else between this tool's read and its write is DELETED rather than merged; HaloPSA offers no optimistic-concurrency token here, so avoid appending to a quote somebody is editing in HaloPSA at the same time. VERIFIED HaloPSA BEHAVIOUR (live test 2026-09-01): 'baseprice' DOES persist on a newly added line — on a free-text line and an item-linked line alike — so set it here rather than trying to change it later; on an EXISTING line HaloPSA ignores a baseprice edit. 'description' is not stored on quotation lines: put the line's text in 'name'. The write also populates the quote header's 'site_delivery_override' from the quote's site if it was empty; no other header field (status, title, client, user, totals) is touched. A batch must name exactly ONE quotation — a flat array whose lines disagree about 'qhid' or omit it is refused before anything is sent, because the write targets one quote's line set.

[HaloPSA] Approve or reject a quotation. This changes the quotation status and may trigger downstream workflows such as invoice or sales order creation. Provide the approval details as a JSON object.

[HaloPSA] Create a new quotation/quote. This creates a sales document visible to staff and optionally clients. Returns the created quotation with its assigned ID. Provide quotation details as a JSON object — use halo_list_clients to find valid client IDs. IMPORTANT: use HaloPSA's real field names on line items or the sell price silently drops to zero. On each line, the SELL price is 'baseprice' (unit list price) and/or 'current_price'; the QUANTITY is 'current_quantity'; the unit COST is 'costprice'. Halo does NOT recognize 'unit_price' or 'quantity' and will ignore them, leaving the line at $0 revenue. ALWAYS ALSO SEND 'price' (the unit sell price, the SAME value as baseprice) on every line. KNOWN HaloPSA BEHAVIOUR (customer-reported 2026-08-31 and again 2026-09-15, INSTANCE-SPECIFIC): on some HaloPSA instances the create response echoes back the 'baseprice' you sent but a later halo_get_quotation reads baseprice 0.0 on EVERY line while 'costprice' and 'current_price' persist — and HaloPSA computes the quote header's total/cost/profit/revenue from baseprice, so the whole quote then reads as a zero-total quote. Live A/B 2026-09-01 on an instance that zeroes: the SAME create with 'price' on each line persisted baseprice, the line totals and the header totals; a reference instance persisted baseprice with or without it. So 'price' is harmless where it is not needed and the field that persists where it is. Building the line from a catalogue item ('item_id' / 'productcode') is NOT a workaround for the zeroing. StackJack's request demonstrably carries the fields, so when it still happens it happens on HaloPSA's side after it answers. ALWAYS read the quote back with halo_get_quotation and check the line prices before treating it as ready to send; if baseprice still came back 0 with 'price' sent, set the sell price on HaloPSA's own quote screen and raise it with HaloPSA support with the line payload.

[HaloPSA] Retrieve a single quotation by numeric ID. Returns full quotation details including line items, pricing, client, and approval status. Requires a valid quotation ID — use halo_list_quotations to find IDs.

[HaloPSA] List quotations/quotes with optional filters. Returns quotation summaries including ID, client, status, total amount, and validity dates. Use this to browse quotes or find specific quotations before fetching full details with halo_get_quotation.

[HaloPSA] Remove one or more EXISTING line items from a quotation. Provide the quotation id and a JSON array of the line ids to remove, for example [10, 11]. Use halo_get_quotation to read the current line ids first. HOW THE REMOVAL WORKS: HaloPSA publishes no per-line delete for quotation lines, so the tool reads the quote and writes its line set back through the quote upsert (POST /Quotation) WITHOUT the lines you named. That upsert REPLACES the quote's line collection, which is what makes the omission a deletion. Every other line is carried through unchanged, exactly as it was read, including the fields you never mentioned. It then reads the quote back and fails loudly unless every id you named is gone AND every other line that existed before the write survived; HaloPSA's 200 on its own is not proof that anything was removed. A line id that does not exist on the quote is refused before anything is sent, and the refusal names the missing ids. Because the tool reads then writes, a line ADDED by someone else between this tool's read and its write is DELETED, not merged, and HaloPSA offers no optimistic-concurrency token on this endpoint to close that window; avoid running this against a quote somebody is editing in HaloPSA at the same time. A removal cannot be undone by re-running this tool: to put a line back, add it again with halo_add_quotation_lines.

[HaloPSA] Update EXISTING line items on a quotation (change pricing/quantity on lines that already exist). Use halo_add_quotation_lines to append brand-new lines. Provide the quotation id plus the lines to change — use halo_get_quotation to see current line ids and their fields first. HOW THE WRITE WORKS: HaloPSA has no working quote-line endpoint (POST /Quotation/Lines answers 200 and writes nothing, and there is no /Quotation/updatelines), so the tool reads the quote, overlays your changes onto the current lines by line id, and re-sends the COMPLETE line set through the quote upsert. Lines you do not mention are carried through unchanged; only the fields you name on the ids you name are altered. It then reads the quote back and fails loudly when Halo matched none of the submitted lines (change_seq unchanged), discarded the submitted values, or stored a value that is neither what you submitted nor what the line held before (a Halo-side normalization and someone else's concurrent edit look identical here, so that case is reported as unverified rather than success — re-read the quote with halo_get_quotation instead of retrying automatically), or could not verify a submitted property AT ALL because the read-back gives it no stored value to compare against (a field name Halo does not recognize is the commonest cause; the write itself may well have landed, so that verdict says only that StackJack could not confirm it); Halo's 200 alone is not proof of persistence. Because the tool reads then writes, two concurrent edits to the same quote end in last-writer-wins — and on this endpoint that is sharper than usual: the write REPLACES the quote's whole line collection with the set read a moment earlier, so a line ADDED by someone else between this tool's read and its write is DELETED, not merged. HaloPSA offers no optimistic-concurrency token on this endpoint, so that window cannot be closed from here; 'change_seq' is checked AFTER the write as evidence, not before it as a lock. Avoid running this against a quote somebody is editing in HaloPSA at the same time. VERIFIED HaloPSA BEHAVIOUR (live test 2026-09-01): 'baseprice' is settable when a line is CREATED but is IGNORED when an existing line is updated — it keeps its original value while current_price, current_quantity and costprice all change as submitted. To change the sell price of an existing line, set 'current_price'; to change baseprice, delete the line and add it again with halo_add_quotation_lines. 'description' is not stored on quotation lines either — the line's text field is 'name'. The write also populates the quote header's 'site_delivery_override' from the quote's site if it was empty; no other header field (status, title, client, user, totals) is touched. A batch must name exactly ONE quotation — a flat array whose lines disagree about 'qhid' or omit it is refused before anything is sent, because the write targets one quote's line set.

[HaloPSA] View a quotation in a rendered/presentable format. Returns the quotation formatted for viewing, including all line items, totals, and client details. Provide the request details as a JSON object including the quotation ID. Use this when you need a presentation-ready view of a quote rather than raw data.

[HaloPSA] Create a new product/item in the catalogue. This adds a new sellable or trackable item. Returns the created item with its assigned ID. Provide item details as a JSON object.

[HaloPSA] Create a link between an item and an accounting system account. This maps a product to a revenue or expense account for financial reporting. Provide link details as a JSON object.

[HaloPSA] Create a new item group/category for organising products in the catalogue. Returns the created group with its assigned ID. Provide group details as a JSON object.

[HaloPSA] Link a supplier to an item/product. This creates a procurement relationship between a supplier and an item, optionally with supplier-specific pricing. Provide link details as a JSON object.

[HaloPSA] Create a new stock bin/warehouse location for storing inventory. Returns the created bin with its assigned ID. Provide bin details as a JSON object.

[HaloPSA] Delete an item group by numeric ID. This permanently removes the group. Items in the group are not deleted but become ungrouped. Use with caution — this cannot be undone. Requires a valid group ID — use halo_list_item_groups to find IDs.

[HaloPSA] Remove a supplier link from an item by numeric link ID. This removes the procurement relationship between a supplier and an item. Use with caution — this cannot be undone. Use halo_list_item_suppliers to find valid link IDs.

[HaloPSA] Delete a stock bin/warehouse location by numeric ID. This permanently removes the bin. Stock items in the bin should be transferred first. Use with caution — this cannot be undone. Requires a valid bin ID — use halo_list_stock_bins to find IDs.

[HaloPSA] Retrieve a single product/item by numeric ID. Returns full item details including name, SKU, description, pricing, and stock levels. Requires a valid item ID — use halo_list_items to find IDs.

[HaloPSA] Retrieve a single item group by numeric ID. Returns full group details including name, description, and linked items. Requires a valid group ID — use halo_list_item_groups to find IDs.

[HaloPSA] Retrieve a single stock bin/warehouse location by numeric ID. Returns full bin details including name, address, and current stock summary. Requires a valid bin ID — use halo_list_stock_bins to find IDs.

[HaloPSA] List accounting integation links for items. Returns mappings between items and accounting system accounts (e.g., revenue accounts, expense accounts). Use this to review or audit how items are mapped to your accounting software.

[HaloPSA] List item groups/categories used to organise products in the catalogue. Returns group IDs, names, and hierarchy. Use this to discover valid group IDs for filtering items or assigning new items to groups.

[HaloPSA] List stock levels for items/products. Returns current stock quantities, locations, and reorder thresholds. Use this to check inventory levels or identify items that need restocking.

[HaloPSA] List stock level history for items, showing how inventory quantities have changed over time. Optionally filter by item ID or specific stock record. Use this for inventory trend analysis and auditing stock adjustments.

[HaloPSA] List supplier links for items/products. Returns which suppliers provide which items, including supplier-specific pricing and SKUs. Use this to review procurement options or find alternative suppliers for items.

[HaloPSA] List products/items in the catalogue with optional search filter. Returns item summaries including ID, name, SKU, price, and category. Use this to browse the product catalogue or find items for quotations, invoices, or purchase orders.

[HaloPSA] List stock bin/warehouse locations where inventory is stored. Returns bin IDs, names, and location details. Use this to discover valid storage locations for stock management and transfers.

[HaloPSA] List stock trace records showing the movement history of inventory items. Returns transfer records including source, destination, quantity, and timestamps. Use this for inventory auditing and tracking item movements between bins or locations.

[HaloPSA] Confirm receipt of goods on a purchase order. This updates stock levels and marks items as received. Provide receipt details as a JSON object — use halo_get_purchase_order to see current PO line items.

[HaloPSA] Create a new purchase order. This creates a procurement document for ordering from suppliers. Returns the created PO with its assigned ID. Provide PO details as a JSON object — use halo_list_suppliers to find valid supplier IDs.

[HaloPSA] Retrieve a single purchase order by numeric ID. Returns full PO details including line items, supplier, amounts, and delivery status. Requires a valid PO ID — use halo_list_purchase_orders to find IDs.

[HaloPSA] List purchase orders with optional filters. Returns PO summaries including ID, supplier, status, total amount, and date. Use this to browse procurement history or find specific purchase orders.

[HaloPSA] Create a NEW sales order. This creates a sales document for tracking client orders. HaloPSA answers 201 with the created order, including the id it assigned to the order and to each line. Use halo_list_clients to find valid client IDs and halo_list_items for product IDs. REQUIRED: 'client_id' AND 'user_id' (the ordering contact). Without 'user_id' HaloPSA refuses the create with 400 "Please select a valid User" (verified on a live instance, 2026-09-11). LINE FIELDS (verified the same day): 'name' is the line text, 'productcode' the item code, 'quantity' the quantity, 'price' the unit sell price that drives the line total, 'baseprice' the unit list price (stored separately, it does not drive the total), 'costprice' the unit cost, 'note' a free-text note. HaloPSA's order line has no 'unit_price' field and ignores that name entirely. Example: {"client_id": 12, "user_id": 26, "lines": [{"name": "Widget", "productcode": "W-1", "quantity": 2, "price": 499.99, "costprice": 300.00}]}. This tool CREATES only: a payload carrying an existing order 'id' is refused, because HaloPSA's POST api/SalesOrder is an upsert whose 'lines' REPLACE the order's whole line collection, so every line the payload left out would be deleted. To change existing lines use halo_update_sales_order_lines, which reads the order first and re-sends its complete line set.

[HaloPSA] Retrieve a single sales order by numeric ID. Returns full order details including line items, client, amounts, and fulfilment status. Requires a valid sales order ID, use halo_list_sales_orders to find IDs.

[HaloPSA] List sales orders with optional filters. Returns order summaries including ID, client, status, total amount, and date. Use this to browse sales history or find specific orders.

[HaloPSA] Update EXISTING line items on a sales order (change price, quantity or text on lines that already exist). Provide each line's own 'id' plus the parent 'salesorder_id'. Use halo_get_sales_order to read the current line ids and their fields first. HOW THE WRITE WORKS: HaloPSA has no working sales-order line endpoint (POST api/SalesOrder/updatelines answers 405), so the tool reads the order, overlays your changes onto the CURRENT lines by line id, and re-sends the COMPLETE line set through the order upsert (POST api/SalesOrder). Lines you do not mention are carried through unchanged, and every field of every line is re-sent exactly as it was read. That is not defensive: a body carrying only PARTIAL line objects answers 200 and echoes your edit back while persisting NOTHING (verified live 2026-09-11), and a line left out of the body is DELETED. It then reads the order back and returns that read-back, failing loudly when a line that existed before the write is gone, when an edited field does not hold the submitted value on the read-back, or when a header field the tool never sent has moved. HaloPSA's 200 and its echoed body are never proof of persistence on this endpoint. FIELDS THAT PERSIST (all verified live 2026-09-11): 'quantity' (a real, writable line field), 'price' (the unit SELL price, and the one that drives the line total: quantity x price), 'baseprice' (the unit list price, stored separately and NOT used for the total), 'costprice' (the unit cost), 'name' (the line text), 'productcode', and 'note'. There is no 'unit_price' field on a Halo order line. An earlier version of this description claimed the order line has no 'quantity' field; that was wrong and is corrected here. Because the tool reads then writes, two concurrent edits to the same order end in last-writer-wins, and on this endpoint that is sharper than usual: the write REPLACES the order's whole line collection with the set read a moment earlier, so a line ADDED by someone else between this tool's read and its write is DELETED, not merged. HaloPSA offers no optimistic-concurrency token on this endpoint, so avoid running this against an order somebody is editing in HaloPSA at the same time. A batch must name exactly ONE sales order: lines that disagree about 'salesorder_id', or omit it, are refused before anything is sent, because one write targets one order's line set.