Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr — BU Project Structure.

This episode covers how Dolibarr projects, tasks, and tickets are organised across NZRT’s business units, and how agent tickets connect to the right place every time.

Let’s start with the big picture — how the structure is actually shaped inside Dolibarr. Think of it as three layers sitting inside each other. At the top level you have a Dolibarr Project, and there is one of these for each business unit. Inside that project you have Tasks, which represent functional areas of work within that business unit. And then inside each task you have Tickets — these are the specific work items that get assigned to individual agents. So the chain goes Project, then Task, then Ticket. Every piece of agent work needs to sit correctly within that chain.

Now let’s look at the four business unit projects that currently exist. First up is the API project, which covers the x402 Knowledge Base. Its reference code is the API service code and its Dolibarr ID is 24. Second is the ICS project — that stands for Internet Consulting Services — service code ICS, Dolibarr ID 25. Third is the ITE project, which is the Iteasel product — the portable wooden display easel — service code ITE, Dolibarr ID 26. And fourth is NCS, which is NZRT Charitable Services, service code NCS, Dolibarr ID 27. So you’ve got four projects, each with its own ID you’ll need when creating or linking tickets via the API.

Inside each of those four projects, you’ll find the same four standard tasks. Every BU project has these, which keeps things consistent across the board. The first task is Marketing and Promotion — this covers WordPress pages, forum posts, and external communications. The second is Technical Development, which is where scripts, API work, deployments, and integrations live. The third is Client Delivery, covering things like SOPs, proposals, onboarding, and handover. And the fourth is Operations, which handles scheduling, reporting, admin, and monitoring.

Next, let’s talk about how tickets get assigned. This is where the agent capability matching comes in. If a ticket sits under a Marketing and Promotion task, it goes to pam. Client Delivery tickets on the sales side go to cas. Operations tickets dealing with invoicing go to fin. Technical Development tickets — things like API work and infrastructure — go to cla. And dai picks up reporting and analytics tickets regardless of which task they sit under. So dai’s scope crosses all four task types when the work involves reporting.

When you’re creating a ticket, there are two key fields you need to set. You use the project field to link the ticket to the correct BU project, and you use the task field to link it to the correct task within that project. You also need to make sure the category tag matches the BU service code — that’s the category table in Dolibarr that ties the ticket to the right business unit bucket.

Finally, a quick note on the reference format you’ll see on these projects. Each project reference follows the pattern WPS-CPL-BUS followed by the BU code. So for example you’d see WPS-CPL-BUS-ICS for the Internet Consulting Services project. Breaking that down: WPS stands for Work Package System, CPL stands for cPanel, BUS stands for Business Unit, and then the final part is the specific code — API, ICS, ITE, or NCS. This convention is also connected to the TOGAF Work Packages context, so if you’re working in that space you’ll see these references appearing there too.

To bring it all together — when an agent needs to do any piece of work, you look at what kind of work it is, find the right BU project by service code and Dolibarr ID, drop into the matching standard task, and create the ticket with both the project and task fields correctly set and the right category tag applied. That three-level structure — Project, Task, Ticket — is what keeps everything traceable and correctly attributed across the four NZRT business units.

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