Agent Workflow In Dolibarr

Welcome to the NZRT Wiki Podcast. Today we’re looking at Agent Workflow in Dolibarr.

If you’ve ever wondered how NZRT’s virtual agents actually get things done inside the Dolibarr ERP system, this episode breaks that down from start to finish. There are eight agents in the NZRT system. You’ll hear them referred to by their short codes: cas, dai, dan, ema, fin, han, pam, and sun. Each one is a specialist, and Dolibarr is the central place where their work gets organised, tracked, and closed out.

So how does it all start? Everything begins with a ticket. When Claude, the orchestrating agent known as cla, or an automation script needs one of the eight agents to do something, it creates a Dolibarr ticket and assigns it to that agent. That assignment is done using a field that points directly to the agent’s user account inside Dolibarr. No ticket, no work. That’s the rule.

Now, each agent has their own personal API key stored securely in the credentials file on the local system. When an agent makes a request to Dolibarr, they include that key in the request header. The base address they connect to is the NZRT ERP server’s API endpoint. One important thing to know here: an agent’s personal key only gives them visibility of tickets assigned to them. If you need to create a ticket for an agent, or you need to read across all agents at once, you have to use the admin key belonging to xc, the system administrator account.

Let’s walk through what a normal working cycle looks like for an agent. First, the agent fetches their open tickets by calling the get-open-tickets function, passing in their API key and their user ID. That returns the list of things waiting for them. Second, the agent reads the ticket, looking at the subject, the body message, and the category, because that combination tells the agent exactly what kind of task they’re being asked to do. Third, the agent goes off and does the actual work. That might mean posting something to the forum, writing a blog summary, completing an analysis, or handling an intake request. Fourth, once the work is done or progress has been made, the agent records what they did by adding a message to the ticket. And fifth, when everything is wrapped up, the agent closes the ticket and records the resolution.

Now, the tickets themselves are created by a set of Python scripts that live in the main agent repository. There are different scripts for different kinds of work. One script handles forum post tickets, another handles blog summary tickets for the agent called pam, another is for intake tickets coming through the NCS charitable services side of the business, another handles general ad-hoc operations tickets, and there’s one dedicated script that creates all eight TOGAF phase tickets in bulk at once. That last one is particularly handy because TOGAF work involves all agents simultaneously.

Let’s talk about what each agent is actually responsible for inside Dolibarr. There are eight agents, and their module access reflects their specialisation. Cas works with customer relationship management, orders, invoices, and third-party records. Dai has broad read access across reports, exports, and analytics. Fin handles accounting, bank accounts, and payments. Pam focuses on products and catalogue synchronisation. Sun deals with purchase orders and supplier records. Ema manages electronic documents. Han handles human resources, though it’s worth noting that HR support through the REST API is limited. And then there’s dan, who is a special case: dan doesn’t use the Dolibarr REST API at all and instead works directly with the underlying database through MySQL.

Speaking of limitations, there are a couple of known constraints worth knowing about. Ticket notes, whether public or private, are not returned by the REST API. That means if you want to read them, you have to go into the Dolibarr graphical interface directly. Also, when it comes to managing module permissions or agent user roles, that has to be done via direct MySQL access rather than through the REST layer.

So to summarise the big picture: Dolibarr is the engine room for all agent work at NZRT. Tickets come in, agents pick them up using their personal API keys, they do the work, they record it, and they close the ticket out. The scripts in the agent repository handle ticket creation, and each agent’s access is scoped to exactly what they need for their role. The xc admin key sits above all of it for cross-agent visibility and ticket creation.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.