--- title: "Jitbit Helpdesk Integration" description: "Connect AI agents to Jitbit Helpdesk, a ticketing helpdesk available as SaaS or self-hosted. Agents open tickets, post comments, route by category, and keep user and custom field data current." url: https://flowrunner.ai/integrations/jitbit date_modified: 2026-08-11T09:36:14-07:00 --- # Jitbit Helpdesk [Helpdesk & ITSM](https://flowrunner.ai/integrations/category/helpdesk-itsm) Connect AI agents to Jitbit Helpdesk, a ticketing helpdesk available as SaaS or self-hosted. Agents open tickets, post comments, route by category, and keep user and custom field data current. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 20 actions · Basic auth · available [Jitbit Helpdesk website](https://jitbit.com/) · [Platform Documentation](https://www.jitbit.com/) · Capability data verified 2026-08-05 1. A joiner, mover, or leaver record lands from the HR system on a schedule 2. Agent runs Get User By Email to find out whether the person already has a helpdesk account 3. Agent runs Create Ticket in the IT Onboarding category with the requested access listed 4. Agent runs Get Technicians For Category to find who can actually take the work 5. Agent runs Update Ticket to set the assignee and due date, and Set Ticket Custom Field to record the cost centre 6. IT lead receives the account changes the request implies, stated explicitly 7. IT lead approves before Update User changes an admin flag or disables an account ## What This Integration Enables Jitbit is the ticketing helpdesk that runs the same way whether you buy it hosted or install it on your own server, and this connector works against either. The only configuration difference is the helpdesk URL. That matters more than it sounds, because it means an internal IT desk sitting behind a corporate firewall gets the same automation surface as one on the public internet, and the flows you build do not need rewriting if the deployment moves. The connector's shape is unusual for a helpdesk in one important way: it exposes a full user administration surface alongside the ticket surface. Create User, Update User, List Users filtered by role or department or company, Get User, and Get User By Email are all here, and Update User can set the administrator flag or the disabled state on an account. That makes Jitbit a genuine identity touchpoint rather than just a queue. It also means authentication carries real weight, because requests authenticate as a specific helpdesk user or technician and every action executes with that person's permissions. There is no service identity to hide behind. Whatever the agent does, it does as somebody, and the audit trail says so. Ticket work itself is comprehensive: create, update, close, full text search, secondary assignees for collaboration, public replies and technician only notes through one Add Comment action, category based routing with a per category technician list, and custom field values set individually on a ticket. ### Without FlowRunner **Access requests arrive as email**: The request, the approval, and the change end up in three different places **Account changes leave no ticket behind**: Someone is made an administrator and the only record is a chat message **Closures are silent by accident**: A ticket is closed with notifications suppressed and the requester is never told ### With FlowRunner **Every request opens a ticket first**: Create Ticket puts the request on the record before anything is changed **Privilege changes are proposed, then approved**: Update User runs after a named person signs off on the specific flag being set **Notification suppression is a stated choice**: Closing without emailing the requester is something the approver opts into, not a default ## Use Case Scenarios ### Access request that leaves a paper trail An access request arrives from a manager. The agent runs Get User By Email to see whether the person already has an account, then Create Ticket in the Access Requests category with the specific systems requested written into the body and the manager set as the requester. It runs List Categories and Get Technicians For Category to find who can take the ticket in that category, sets the assignee and a due date with Update Ticket, and records the approving manager and the cost centre with Set Ticket Custom Field. When a change to the Jitbit account itself is required, that step waits for approval. The ticket is the record, and it exists before any privilege moves. ### Duplicate detection before a new ticket opens Two people report the same outage forty seconds apart. The second report reaches the agent, which runs Search Tickets with the error string scoped to the last hour and finds the first ticket already open and assigned. Instead of creating a duplicate, it runs Add Comment on the existing ticket as a technician only note recording the second reporter and their details, runs Add Secondary Assignee to pull in the network technician whose component is implicated, and replies to the second reporter separately. The queue stays clean and the on call engineer is looking at one incident rather than two halves of it. ### Change ticket driven from the deployment pipeline A release is cut in [GitHub](https://flowrunner.ai/integrations/github). The agent opens a change ticket with Create Ticket in the Change Management category, writes the release notes and affected services into the body, and sets priority from the change class using List Priorities to resolve a valid value. As the deployment progresses it posts progress with Add Comment as internal notes. When the deployment succeeds it runs Close Ticket, and when it fails it runs Update Ticket to raise priority and reassign to the on call technician, with a page raised through [PagerDuty](https://flowrunner.ai/integrations/pagerduty). The change record is complete without anyone typing it up afterwards. ## Human-in-Loop Highlight Update User is the action on this connector that stops being a helpdesk operation and becomes an identity operation. It can set the administrator flag on an account, and it can set the disabled state, which locks a real person out of the desk they work in all day. That risk is sharpened by how the connector authenticates: it runs as a named helpdesk user or technician, and every action executes with that person's permissions, so an over privileged automation account quietly becomes a way for a flow to grant privileges it was never meant to grant, with a colleague's name on the change. So the agent gathers everything and stops. It runs Get User to capture the account's current state, states the delta rather than the intent, and asks: "Ticket 8842 requests administrator access for j.okafor@example.com in the Finance department. The account is currently a regular user, enabled, created 2024-11-03. This flow is authenticated as technician m.reyes. Set the administrator flag, or decline and reply on the ticket?" A person answers, the change is made under a decision someone owns, and the ticket carries the record. A second, quieter gate belongs on Close Ticket, which can suppress the notification email that normally tells the requester their ticket is done. Suppressing it is occasionally right and frequently how a customer ends up waiting on something that was closed a week ago, so it is an option a human selects rather than a default an agent inherits. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via email Human decides Agent resumes with decision ## Agent Capabilities 20 actions ### Tickets 8 - **List Tickets** Retrieves a paginated list of tickets, filterable by mode, category, status, requester, assignee, tag, or date range, with the mode filter covering common views such as all, unanswered, unclosed, and handled by me. Used for queue reporting and backlog sweeps. - **Get Ticket** Retrieves the full details of a single ticket including subject, body, status, category, priority, requester, and assignee. Used to confirm current state before an update. - **Create Ticket** Creates a ticket in a category with a subject, body, and priority, optionally setting requester, assignee, tags, and origin, returning the new ticket ID. Used to put a request on the record before anything is acted on. - **Update Ticket** Updates category, priority, status, assignee, due date, subject, or body, changing only the fields supplied. Used to reassign, reprioritize, and move a ticket through its lifecycle. - **Close Ticket** Closes a ticket by ID, optionally suppressing the notification email normally sent to the requester. Suppression is a deliberate choice, not a default, because a silently closed ticket leaves the requester waiting. - **Search Tickets** Performs a full text search across tickets, optionally scoped by requester, category, or date range. Rate limited to 60 requests per minute. Used for duplicate detection before a new ticket is opened. - **Add Secondary Assignee** Adds an additional technician to a ticket alongside the primary assignee. Used to pull a specialist into an incident without taking ownership away from whoever holds it. - **List Priorities** Retrieves the ticket priority values available, covering the standard Low, Normal, High, and Critical plus any custom priorities configured. Used to resolve a valid priority rather than guessing at a label. ### Comments 2 - **Add Comment** Posts a comment to a ticket, either public and visible to the requester or restricted to technicians only, with HTML supported in the body. The public flag is the boundary between a customer facing reply and an internal note, so it is worth setting explicitly on every call. - **Get Comments** Retrieves all comments on a ticket, replies and internal notes together, in chronological order. Used to read what has already been said before adding to it. ### Categories 2 - **List Categories** Retrieves the ticket categories the authenticated user can access, with IDs, names, and section grouping. Used to route a ticket into a category that exists and that this identity can see. - **Get Technicians For Category** Retrieves the technicians eligible to be assigned tickets in a specific category. Used to pick a valid assignee instead of assigning work to someone who cannot take it. ### Users 5 - **List Users** Retrieves a paginated list of users filterable by role, department, or company. Requires administrator access. Used for reconciliation against an HR or directory system. - **Get User** Retrieves a single user's details by numeric user ID. Used to capture an account's current state before proposing a change to it. - **Get User By Email** Retrieves a single user's details by email address. Rate limited to 60 requests per minute. Used as the existence check at the head of any onboarding flow. - **Create User** Creates a user account, requiring an email and optionally setting username, password, name, phone, location, company, department, and whether to send a welcome email. Returns the new user ID. - **Update User** Updates a user's username, email, name, company, admin flag, or disabled state, changing only the fields supplied. Because this can grant administrator rights or lock someone out, it runs only after human approval. ### Custom Fields 3 - **List Custom Fields** Retrieves the custom field definitions configured for a given owner type across tickets, assets, users, or companies, with IDs, names, and types. Used to discover the field to write before writing to it. - **Get Ticket Custom Fields** Retrieves the custom field values set on a specific ticket, optionally including fields that have not been set. Used to read structured metadata such as cost centre or asset tag. - **Set Ticket Custom Field** Sets the value of a single custom field on a ticket by custom field ID. Used to record the approver, the cost centre, or any other structured field the desk reports on. --- The Jitbit connector exposes no FlowRunner triggers, so nothing here listens for events. Flows react on a schedule that calls List Tickets, typically using the unanswered or unclosed mode filters, and diffs against the previous run. Note the rate limits when designing that sweep: most endpoints allow 90 requests per minute, while Search Tickets and Get User By Email allow 60. ## Frequently Asked Questions ### What can FlowRunner do with Jitbit Helpdesk? FlowRunner agents can run List Tickets, Get Ticket, and Create Ticket in Jitbit Helpdesk, plus 17 more actions. ### Does connecting Jitbit Helpdesk to FlowRunner require OAuth? No. Jitbit Helpdesk connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can Jitbit Helpdesk trigger a FlowRunner workflow automatically? Jitbit Helpdesk doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Jitbit Helpdesk?** This integration exposes Jitbit Helpdesk to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/jitbit. Site index: https://flowrunner.ai/llms.txt