Jitbit Helpdesk
Helpdesk & ITSMConnect 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.
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
With FlowRunner
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. 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. 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 Capabilities
20 actionsTickets
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.
Start building with Jitbit Helpdesk
$100 in credits. No card required. Connect in minutes.