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.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Commercial Proposals (Quotes).

If you’ve ever needed to send a client a formal price breakdown before they commit to anything, you’re working with what NZRT calls a Commercial Proposal, or simply a Quote. These are professional PDF documents that give your customer a clear picture of what you’re offering, what it costs, and what they’re agreeing to. And the good news is they’re built to do a lot of the heavy lifting for you, from calculation through to signature and straight into an order, all without having to re-enter the same information twice.

Let’s start with the overall journey a quote takes from the moment you create it. It begins in a draft state. That’s your working space where you’re pulling things together, adding line items, adjusting figures, and making sure everything looks right before anyone outside the business sees it. Once you’re happy with it internally, it moves to validated. Think of that as your internal sign-off, a checkpoint that says this document is ready to go out the door. After that, it gets sent to the customer. From there, the customer can actually sign it online, which we’ll talk about in a moment. And once signed or approved, you can convert it directly into a Customer Order without starting from scratch. So the flow goes from draft, to validated, to sent, to optionally signed online, and finally converted into an order.

Now let’s talk about what actually goes inside one of these quotes. The line items, meaning the individual products or services you’re quoting for, are pulled directly from your catalogue. That means you’re not typing descriptions or prices from memory. You select what you need, and the system brings in the details for you. On top of that, you have full control over discounts, tax, and margin calculations. So if you need to apply a ten percent discount to a particular item, or you want to check whether your margin on a service is healthy before you send the quote out, all of that is handled right there in the quote itself. You can see your numbers clearly and adjust them before anything goes to the client.

When it comes to actually generating the document the customer receives, you have multiple PDF templates to choose from. This matters because different clients or different types of engagements might call for different formats. One template might be more formal and detailed, while another is simpler and more suitable for a quick engagement. You pick the one that fits the situation, and the system generates a professional PDF ready to send.

One of the more powerful features here is the online signing link. When you send a quote, you can include a link that allows the customer to review and e-sign the document directly in their browser. There’s no printing, scanning, or emailing back required. The customer clicks the link, reviews the quote, and adds their signature electronically. This speeds things up significantly, especially when you’re working with clients who aren’t in the same location or time zone. Once they’ve signed, that status is reflected in the system and you can move forward with converting to an order.

Speaking of which, that conversion step is worth highlighting. Because everything in the quote, your line items, pricing, discounts, customer details, flows directly into the resulting Customer Order, you’re not doing double data entry. It’s a clean handoff from the proposal stage to the fulfilment stage.

There’s also version history built in, which is easy to overlook but genuinely useful. If a quote goes through several rounds of revision, perhaps a client asks you to adjust scope or pricing, you have a record of what changed and when. That kind of audit trail is helpful both for your own records and for any disputes or questions that might come up later.

Finally, it’s worth knowing how quotes connect to the rest of the system. They sit naturally alongside Customer Orders, since that’s where a signed quote ends up. They also tie into the Margins module, so your profitability analysis stays connected to what you’re actually quoting. And if you’re tracking opportunities and leads, quotes are often the next step after a lead progresses, giving you a clear line from initial interest all the way through to a signed commitment.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Bill of Materials, or BOM for short.

So what exactly is a Bill of Materials? Think of it as the recipe for a finished product. It tells you every component you need, how much of each one, and how they all fit together before you can produce your end result. If you’ve ever followed a recipe that said “to make this dish, you need these ingredients in these amounts,” a BOM works on exactly the same principle, just applied to manufacturing and assembly.

Let’s walk through the structure of a BOM, because this is where it gets really clear. Imagine you’re looking at a diagram on screen. At the very top you have your finished product. Hanging off that finished product are three components: Component A, Component B, and Component C. Component A requires two pieces. Component B requires half a kilogram. And Component C requires one metre. Now here’s where it gets interesting. Component B itself has a child underneath it called Sub-component B1. That means your BOM isn’t just a flat list. It can be multi-level, going deeper and deeper as needed. You might have a component that is itself made up of other parts, and those parts might have their own sub-parts. This nesting is what makes a BOM powerful, because it captures the full picture of what goes into your product at every level of assembly.

Now let’s talk about the key fields you’ll encounter when you’re working with a BOM in practice.

First, you have your finished product itself, along with the quantity that particular BOM produces. So if one run of this BOM produces ten units, that’s recorded right at the top level.

Next, you have your individual components, each with their own quantities and units. And as you saw in the structure example, those units can vary. One component might be measured in pieces, another in kilograms, another in metres. The system handles all of that, so you don’t have to convert anything manually.

Then there’s something called the scrap factor. This one’s worth paying attention to. When you set a scrap factor on a component, the system automatically over-allocates that material. In other words, if you know from experience that you lose a certain percentage of a raw material during production due to waste or off-cuts or spoilage, you tell the BOM that, and it will automatically request more than the theoretical minimum. You don’t have to manually calculate that buffer every time you create a manufacturing order. It’s baked right in.

Finally, there’s the work centre field. This tells the system where in your facility or production setup a particular component or assembly step happens. Different components might be processed in different locations, and the work centre field captures that routing information.

Now, a BOM doesn’t exist in isolation. It connects to two other important areas of the system. The first is Manufacturing Orders. When you actually want to produce something, you create a Manufacturing Order, and that order executes the BOM. Think of the BOM as the plan and the Manufacturing Order as the action. The BOM says “here’s what you need and how much,” and the Manufacturing Order says “okay, let’s actually make it now.”

The second connected area is Stock and Warehouse Management. When a Manufacturing Order is created from a BOM, the system uses the component list to reserve stock from your warehouse. So if you need two pieces of Component A, the system checks whether you have them available, and reserves them so they don’t get allocated to something else in the meantime. This tight link between your BOM and your stock levels means you always have visibility into whether you actually have what you need before you commit to production.

To bring it all together: a BOM is your single source of truth for what a product is made of. Get it right, and everything downstream, your manufacturing orders, your stock reservations, your scrap allowances, flows from it automatically. Get it wrong, and you’ll find yourself short on materials or producing more waste than you planned for.

Whether you’re setting up a BOM for the first time or reviewing an existing one, the key things to check are that every component is listed with the correct quantity and the right unit of measure, that scrap factors reflect your real-world waste experience, and that work centres are assigned where relevant.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr Beneficiary Records — NCS Charitable Services.

If you work with the NCS charitable services side of NZRT, you’ll want to understand how beneficiary organisations are tracked inside Dolibarr. This episode walks you through the record schema, how records get created, what delivery notes look like, and how to query those records via the API.

Let’s start with the basics. In Dolibarr, beneficiary organisations are stored as Third Parties — the same entity type used for commercial customers. The key difference is that these records are flagged as customer type, not supplier, and importantly, no invoicing ever happens against them.

Here’s how the record fields break down. There are seven main fields to know about. The name field holds the organisation’s name, taken directly from their application email. The client field is set to one, which marks this as a customer or beneficiary type. The supplier field is set to zero, because these organisations are not suppliers. The email field holds the applicant’s email address as the primary contact. The status field is set to one, meaning active, and that’s applied at the time of creation. The organisation type field is left as the Dolibarr default, depending on whether New Zealand organisation types are configured in your instance. And finally, there’s a private note field — this is where you record what services were delivered and when, either manually or via an agent note.

Now, how do these records actually get created? For most NCS workflows, you don’t have to do this by hand. Records are created automatically by the CAS agent when it processes an approved application through the charitable delivery workflow. But if you ever need to create one manually through the Dolibarr user interface, here’s the process. You navigate to Third Parties, then New Third Party. You set the name, the email, and make sure the client flag is set to one. You save the record and note the ID Dolibarr assigns. Then you add a private note documenting the delivery.

Speaking of delivery records — this is an important one. Because NCS charitable delivery is at no cost, you never raise an invoice for these. Instead, the delivery is documented in that private note field. A typical note would say something like: NCS delivery on the 27th of April 2026, listing the services delivered — for example Knowledge Systems and Claude Code AI Agent Setup — noting that delivery was made via automated email from the NZRT sales address, and recording which email address the GitHub zip files were sent to. That’s essentially a plain-language delivery receipt sitting right inside the record.

Now, if you ever need a more formal paper trail — say for charitable registration evidence or reporting purposes — there is an option to create a zero-dollar commercial proposal. You’d set the beneficiary organisation as the third party, add one line per service delivered with a unit price of zero, then validate and close it. This gives you a proper document record without creating any payment obligation. It’s purely for audit and reporting.

Finally, let’s talk about querying beneficiary records. If you’re pulling data via the Dolibarr REST API using the CAS API key, you send a request to the thirdparties endpoint asking for up to one hundred results and filtering by client type one. In plain terms, that means you’re asking Dolibarr to return all third parties that are flagged as customer or beneficiary type. From there you can filter further by organisation name or by keywords in the private note to zero in on NCS-specific records.

So to recap: beneficiaries live in Dolibarr as Third Parties, flagged as client type with no invoicing, delivery is documented in the private note, and the CAS agent handles creation automatically in most cases. When formal records are needed, a zero-dollar proposal is your tool of choice.

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

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.

Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr — Knowledge Management Module.

So, what is the Knowledge Management module in Dolibarr? At its core, it’s a built-in feature that lets you store reusable Question and Answer records — think of it like an internal FAQ or troubleshooting library, right inside your ERP system. Each record pairs a question — something a team member or agent might actually search for — with an answer or solution. And those records can be linked directly to tickets, so when you’re working on a support issue, relevant knowledge articles can surface right there in the ticket view.

Now, you might be wondering whether this module is actually switched on for NZRT. To check that, a call was made to the Dolibarr knowledge management API endpoint — essentially asking the system to return a list of all existing knowledge records. The API came back with an empty list rather than an error, which tells us the module is confirmed as active and working on our instance. There are just zero records in it right now. So the foundation is there — it’s ready to be used.

Let’s talk about what’s inside a knowledge record. There are a handful of key fields you need to know about. The first is the question field — this is where you put the problem in plain language, the kind of thing you or a future agent would actually type when trying to find help. The second is the answer field, a rich text area where you write a short solution — ideally one to three sentences — with a pointer to where the full detail lives, like a script, a document, or a memory file. The idea is to keep it brief and point outward rather than duplicate information that already exists somewhere else. Third, you have a category field, which uses Dolibarr’s standard category linking. For NZRT, these categories are tagged by system, things like the Dolibarr codebase, WordPress, and so on. Fourth is the status field, which follows a draft to validated lifecycle — matching the same kind of workflow you’d see in the Obsidian vault. And finally, each knowledge record supports linked objects, meaning you can attach a record directly to a ticket, and the ticket system can surface matching articles by searching keywords from the question field.

So why does NZRT actually need this? Right now, a lot of the “I’ve hit this exact problem before” knowledge is scattered — it’s in individual memory feedback files in the dot-claude directory, or buried in sections of the Claude config file, or sitting in deep-reference wiki documents. The Knowledge Management module gives all of that a single home inside Dolibarr, where agents are already working. Instead of hunting across multiple files, you get the relevant fix surfaced right inside the ticket you’re on.

And to be clear about the design here — the source of truth stays in the vault and memory files. Knowledge Management records are short pointers, not full copies. That’s intentional, to avoid a situation where the same fix lives in two places and slowly drifts out of sync. The KM record says: here’s the problem, here’s the short answer, and here’s where to go for the full detail.

Who looks after all of this? Within NZRT, the cla agent owns knowledge record creation and maintenance — this is the AI knowledge layer. The dai agent has read access for analytics and reporting, so you can track which articles are getting linked most often and spot where knowledge gaps exist. And all the other agents — pam, cas, sun, fin, han, ema, and dan — are consumers of this knowledge through the ticket-linked suggestions.

One important thing to note: as of right now, no records have actually been seeded yet. There is a planned Question and Answer seed list that covers recurring gotchas across all NZRT third parties, projects, and tasks — but the seeding pass is a future step. The module is live, the structure is defined, and the design is ready. It’s just waiting for that first batch of records to go in.

If you want to go deeper, the related areas to look at are the Dolibarr ticket system documentation, the business unit project structure that the seed list is organised around, and the Dolibarr Agent Integration guide, which covers how agents actually interact with the system day to day.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr Module List — NZRT.

If you’ve ever wondered exactly what’s switched on inside NZRT’s Dolibarr ERP system, this episode gives you the full picture. Dolibarr is the backbone of NZRT’s operations — handling everything from sales and purchasing through to HR and accounting — and the module list is your map of what’s available and active.

Let’s walk through it section by section.

Starting with Product Management. This covers the Products and Services Catalogue, which is where you define what NZRT sells or delivers. Alongside that you’ve got Stock and Warehouse Management for tracking physical inventory, Barcodes for scanning and labelling, and Batches, Lots and Serials for tracing individual product units. If you’re selling items that come in different configurations, Product Variants handles that. And for anything manufactured in-house, you’ve got the Bill of Materials module and Manufacturing Orders to manage the production workflow.

Moving into Customer and Sales — this is a big one. You start with Customers, Prospects and Contacts as your central relationship database. From there, Opportunities and Leads feeds your pipeline, and Commercial Proposals lets you send quotes. Once a quote converts, Customer Orders tracks it. If you’re managing ongoing agreements, Contracts and Subscriptions and Interventions both come into play. The Ticket System handles support requests, and Partnership Management covers more formal external relationships. On the fulfilment side you’ve got Shipping Management, and on the billing side, Customer Invoices and Credit Notes. There’s also a Point of Sale module if NZRT ever needs to handle in-person transactions.

On the Supplier and Purchase side, the structure mirrors sales. You’ve got Suppliers, Vendors and Contacts as your supplier directory, Supplier Pricing Requests for sending out RFQs, Purchase Orders for confirmed buys, Delivery and Reception for goods-in tracking, and Supplier Invoices and Credit Notes for payables. Incoterms is also available if you’re dealing with international shipping terms.

Finance and Accounting covers the money side broadly. Beyond the core Invoices and Payments module, you’ve got Bank Accounts Management, Direct Debit and Credit Transfer for SEPA transactions, full Accounting Management, Donations Management for any charitable activity, Loan Management, a Margins module to track profitability, and Financial Reports for the overview picture.

Collaboration tools include a Shared Calendar and Agenda so teams can coordinate, the Projects and Tasks module which is central to how NZRT manages its work, Event Organisation for structured events, and Surveys for gathering input.

Human Resources is well covered too. You’ve got Employee and Staff Management as the core record, Employee Leave Management, Expense Reports, Recruitment Management for hiring workflows, and Timesheets for logging hours.

Document Management includes Electronic Document Management for file storage and handling, Bookmarks, Mass Emailing for broadcast communications, an Email Collector to pull inbound messages into Dolibarr, and Data Export and Import tools for moving data in and out.

Administration is the control layer. This is where you manage Users and Groups, configure modules via Module Setup, handle Multi-Company Setup if NZRT operates across entities, and control Security and Permissions across the whole system.

Finally, Integrations. This is where Dolibarr connects outward. There’s a WordPress Integration, the REST API which is how agents and external tools talk to Dolibarr programmatically, Payment Platforms for processing transactions, LDAP Connectivity for directory-based authentication, Google Analytics, and ClickToDial for phone system integration.

So taken together, you’ve got a comprehensive ERP stack — from the moment a lead comes in, through quoting, ordering, fulfilment, invoicing, and all the way through to HR, finance, and external integrations. Every major operational area NZRT runs is represented here.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Dolibarr REST API.

If you’ve been working with Dolibarr and you want to connect it to other systems, pull data out programmatically, or automate repetitive tasks, the REST API is your main tool. It exposes pretty much every entity inside Dolibarr — customers, invoices, products, orders — all through standard web requests. Let’s walk through how it works.

First, the base URL. Every API call you make starts at the same address, which is your Dolibarr instance’s domain, followed by the path api/index.php and then a forward slash. So if your Dolibarr is hosted at erp.yourcompany.com, every endpoint you call will begin with erp.yourcompany.com/api/index.php/ and then whatever resource you’re targeting. That consistent pattern makes it easy to reason about — once you know the base, you just tack on the entity name you want to work with.

Now, authentication. Dolibarr’s REST API uses API key authentication. When you make a request, you include a special HTTP header called DOLAPIKEY, and the value is your personal API key. You don’t need to deal with OAuth flows or token exchanges — it’s a single header on every request. Your API key is something you generate inside the Dolibarr admin interface and then store somewhere secure, like a credentials file or an environment variable. If you’re working in an automated script or agent, you’ll want to pass that key in programmatically rather than hardcoding it anywhere that might end up in version control.

Let’s talk about the key endpoints, because this is where you’ll spend most of your time. Think of each endpoint as the address for a specific type of data in Dolibarr.

There are six main ones covered in the wiki. The first is thirdparties, which covers your customers and suppliers. You can send GET requests to retrieve records, POST to create new ones, and PUT to update existing ones. The second is products, which works the same way — GET, POST, and PUT for reading, creating, and updating your product catalogue.

Third is invoices. Again, GET, POST, and PUT. If you’re building any kind of billing automation — say pulling invoice data into a reporting tool or creating invoices from an external order system — this is the endpoint you’ll be hitting most. Fourth is orders, specifically customer orders, with the same three methods available.

The fifth endpoint is bankaccounts. This one is read-only, so you only have GET available here. It’s useful if you need to retrieve account details as part of a reconciliation process or a financial summary. And sixth is users, also GET only, which lets you pull user records from Dolibarr — handy if you’re syncing user data between systems or need to look up user IDs for assigning tickets or tasks.

So to summarise the pattern: most of the business-critical entities — thirdparties, products, invoices, orders — support full read-write access through GET, POST, and PUT. The more sensitive or administrative resources like bank accounts and users are restricted to read-only access through GET.

One more thing worth mentioning: Dolibarr ships with an interactive API explorer built on Swagger UI. You reach it by going to your instance’s API base path and then adding the word explorer at the end. So it would be your domain, then api/index.php/explorer. This gives you a browser-based interface where you can browse every available endpoint, see what parameters each one accepts, and even fire off test requests directly from the page. If you’re new to the API or you’re trying to figure out the shape of a response before writing code, the explorer is genuinely the fastest way to get familiar with it.

For bulk data needs — like exporting large sets of records for reporting — the wiki points you toward the Data Export feature as an alternative. The REST API is great for targeted, programmatic access and integration work, but if you need to dump thousands of rows at once, the built-in export tools might be a more practical starting point.

To pull it all together: when you’re integrating with Dolibarr, your request always goes to the api/index.php base path, you always include your DOLAPIKEY header for authentication, and you choose your endpoint based on the entity you’re working with. Whether you’re reading customers, creating invoices, updating products, or pulling order data, the structure is consistent and predictable across the board.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Electronic Document Management (EDM).

If you’ve ever wondered how NZRT keeps its documents organised, its emails flowing, and its various platforms talking to each other, EDM is the answer. It sits at the heart of the system as a centralised hub for document storage, email communications, data exchange, and integrations with external services. Think of it as the connective tissue that holds a lot of the day-to-day operational work together.

Let’s walk through what EDM actually covers, starting with its four core sub-modules.

The first is Bookmarks. Just like you’d bookmark a webpage in your browser, this module lets you save and organise references to documents or resources inside the system. It’s a handy way to keep quick access to things you return to often, without having to hunt through folders every time.

The second sub-module is Mass Emailing. This is exactly what it sounds like — the ability to send communications out to large groups of contacts in one go. If you’re managing a campaign, sending out a newsletter, or pushing an update to a list of clients, Mass Emailing is the tool you’d reach for. It’s built directly into EDM so your documents and your outbound communications live in the same ecosystem.

Third is the Email Collector. Where Mass Emailing handles what goes out, the Email Collector handles what comes in. It monitors inboxes and pulls incoming emails into the system so they can be logged, actioned, and tied to the right records. This is particularly important when you look at how EDM connects to the Ticket System — and we’ll come back to that in a moment.

The fourth sub-module is Data Export and Import. This is your bridge between EDM and the outside world in terms of raw data. If you need to bring a bulk set of records into the system, or push data out to another tool or report, this module handles that movement. It supports structured data flows so you’re not copying and pasting things manually.

Now, beyond those four sub-modules, EDM also has a set of broader capabilities worth knowing about.

There’s LDAP integration, which relates to directory services. If your organisation uses a centralised user directory, LDAP allows EDM to connect to it, meaning user accounts and authentication can be managed from one place rather than duplicated across systems.

EDM also supports RSS feed integration. This means you can pull in content feeds from external sources directly into the system, which is useful if you want to monitor news, updates, or any regularly-published external content as part of your workflow.

Social platform linking is another capability. This allows EDM to connect with social media platforms, giving you a way to bridge your document and communication management with your external social presence.

Payment platform integration is also on the list. This one’s particularly relevant if your workflows involve financial transactions or need to reference payment activity. Having that connection inside EDM means you can keep financial context alongside your documents and communications rather than jumping between completely separate systems.

Finally, there’s ClickToDial. This is a feature that lets you initiate a phone call directly from within the system by clicking on a contact’s number. It’s a small quality-of-life feature but a meaningful one if you’re making a lot of outbound calls as part of your work — no manual dialling, no switching apps.

One of the most practically important things to understand about EDM is how it connects to the rest of the platform. Two relationships are called out specifically in the documentation. The first is Integrations — EDM doesn’t operate in isolation. It’s designed to hook into other modules and external services, which is reflected in all those capabilities we just covered. The second is the Ticket System, specifically the email-to-ticket function. When an email comes into the Email Collector, it doesn’t just sit there — it can be automatically converted into a support ticket. This is a powerful workflow for teams managing client requests or support queues, because it means an incoming email becomes an actionable item in your ticketing system without anyone having to manually create that record.

So to bring it all together — EDM gives you centralised document storage, organised bookmarking, outbound mass email, inbound email collection, and structured data movement, all wrapped up with integrations to directories, social platforms, payment systems, phone dialling, and RSS feeds. It’s designed to be the layer of the system that connects communication and documents to action.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at 🔌 Integrations Overview.

So, if you’ve ever wondered how Dolibarr, our core ERP platform, actually talks to the rest of the world, this episode is for you. The short answer is that Dolibarr connects to external systems in three main ways: through a REST API, through webhooks, and through purpose-built connectors designed for specific platforms. Each of these gives you a different kind of bridge between Dolibarr and the tools you use every day.

Let’s walk through the full integration inventory, because there are eight systems worth knowing about here.

The first is WordPress. This is set up as a CMS and portal publishing integration. What that means for you is that Dolibarr can push content and data out to the NZRT WordPress site, so your ERP and your public-facing web presence can stay in sync rather than living in separate silos.

Second is the REST API itself. This is the programmatic access layer, and it’s arguably the most flexible integration of all. If you’re a developer or you’re working with automation scripts, the REST API is how you talk to Dolibarr directly from code. You can create records, query data, update statuses, and much more, all through standard HTTP requests.

Third, you have payment platforms. NZRT has connectors set up for Stripe, PayPal, and Paybox. So when money moves, Dolibarr knows about it. Whether you’re processing client invoices or handling online transactions, these integrations mean payment events can flow back into your ERP records automatically.

Fourth is LDAP, which stands for Lightweight Directory Access Protocol. This one is about directory and single sign-on synchronisation. In plain terms, it means you can connect Dolibarr to a centralised user directory so that staff accounts and permissions can be managed in one place and reflected across systems, rather than having to maintain separate user lists everywhere.

Fifth is Google Analytics. This is a web analytics integration, and it gives you the ability to connect Dolibarr’s web-facing activity to your Analytics reporting. So if you’re tracking portal traffic or user behaviour on pages that tie back to Dolibarr, this connector closes that loop.

Sixth is ClickToDial. This is a VoIP calling integration that works from within the CRM. What that means practically is that you can initiate phone calls directly from a contact or customer record in Dolibarr, which saves time and keeps your call activity tied to the right records without switching between applications.

Seventh is Gmail SMTP. This covers outbound email. When Dolibarr sends emails, whether that’s invoice notifications, automated messages, or system alerts, the Gmail SMTP connector is what routes those messages out through your Google mail infrastructure. It’s the plumbing behind every email Dolibarr sends.

And eighth is the Email Collector. This one works in the opposite direction to Gmail SMTP. Instead of sending email out, the Email Collector pulls inbound email in and converts it into Dolibarr records. So if a client replies to a message, or an email arrives at a monitored inbox, Dolibarr can pick that up and attach it to the right project, ticket, or contact automatically.

Now, one more thing to know about the way NZRT categorises all of this. There’s a service code used internally called 000INT, which stands for the Integration type. Whenever you’re documenting, ticketing, or tracking work that relates to any of these connectors or external system links, that’s the code you’ll see applied. It maps to a broader set of NZRT Service Codes that help keep everything organised across the business.

To summarise what you’ve just heard: Dolibarr sits at the centre of NZRT’s system architecture and reaches outward through eight key integrations. You’ve got WordPress for publishing, the REST API for developer access, three payment platforms covering Stripe, PayPal, and Paybox, LDAP for directory sync and single sign-on, Google Analytics for web reporting, ClickToDial for VoIP from the CRM, Gmail SMTP for outbound email, and the Email Collector for pulling inbound mail into records. All of this integration work falls under the 000INT service code.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at KM Q&A Seed List — All Thirdparties / Projects / Tasks.

This document is a draft seed list for NZRT’s knowledge management system. It hasn’t been pushed to Dolibarr yet — there are currently zero records in the KM module — but this is the source material for a future seeding pass. The data was pulled live from the Dolibarr API on the tenth of June 2026, covering fourteen thirdparties, nineteen projects, and sixty-four standing tasks. TOGAF projects and tasks are intentionally left out of this list and treated as a separate concern.

Before getting into the content, let’s talk about the entry format. Each knowledge management entry has three parts. First, a question — written as something realistic that an agent or team member would actually ask or raise as a ticket. Second, a concise one-to-three sentence answer. And third, a reference pointer to the relevant memory file, configuration section, script, or wiki document where you can dig deeper.

The first major section covers the four business unit projects — the API project for NZRT’s x402 knowledge base, ICS for Internet Consulting Services, ITE for the Iteasel product, and NCS for NZRT Charitable Services. All four share the same four task types. Task one is Marketing and Promotion — pam is the responsible agent, content goes out via WordPress using the wp dot py script, and forum posts go via the forum dot py Python tool. Never use PowerShell for forum posts — session cookies break the CSRF protection. Task two is Technical Development, tracked via system-specific ticket creation scripts with code stored in the matching repository. Task three is Client Delivery, where cas creates the delivery ticket linked to the relevant project and client. Task four is Operations, handled by fin for accounting and sun for procurement.

There’s a specific note for the NCS client delivery task. If a beneficiary submits the intake form but the Dolibarr ticket ends up missing the NCS tag, the problem is in the submission flow. The form posts via AJAX to the WordPress admin handler — not a REST endpoint — and goes through the Dolibarr bridge plugin to create the thirdparty record. The NCS category tag has to be applied via a SQL helper tool because the REST category endpoint isn’t available in this version of Dolibarr.

The second major section covers twelve system and infrastructure projects. For the Obsidian vault, you must read the instructions and schema files before writing any vault note — frontmatter, naming conventions, and cross-linking rules are non-negotiable. For GitHub, you use the gh CLI for GitHub-specific operations and plain git for local commits — never force-push without explicit confirmation. For cPanel and infrastructure, SSH access uses a specific key file and port, restricted to certain network addresses, and on a shared hosting environment you don’t have service restart permissions via SSH — use the cPanel interface instead. For WordPress, content edits go through the REST API via wp dot py, while plugin and theme file changes go through WebDAV. For Dolibarr, the REST API comes first, but for anything it can’t reach — like category tagging or dictionary entries — you drop to SSH and run MySQL directly on the production database. There is no local Dolibarr instance. For Nextcloud, public share links use the OCS sharing API with share type three and read-only permissions, and when uploading TOGAF documents the correct path goes through the Governance subfolder — not directly under the Obsidian root, which is a common mistake. For the Flarum forum, always use Python for posting — a CSRF error is the sign someone used PowerShell instead. For the agent framework, before writing any new script, search the agent repository for an existing ticket creation script first — there are purpose-built scripts with dry-run support for almost every system. And when someone says run pam or run agents, that means cla acts as that agent persona directly, pulls their open Dolibarr tickets, and does the work inline — the run-agents script is deprecated. For Windows operations, PowerShell only — Bash mangles environment variables and path formats. And remember, environment variable values set in one PowerShell call don’t carry over to the next, so set the Dolibarr API key at the top of every command chain that needs it.

The third section covers three vendor and financial projects. BNZ bank transactions are reconciled by fin using Dolibarr’s bank module — currently manual with no automated feed. Bunnings purchases are recorded by sun as supplier invoices against the Bunnings thirdparty. PayPal is treated as a virtual bank account in Dolibarr and reconciled against the payment platform configuration.

On coverage: nineteen of nineteen projects are documented, all sixty-four standing tasks have entries, and fourteen of fifteen thirdparties are covered — The Open Group is excluded because TOGAF is out of scope here. About twenty-five entries are based on documented incidents and existing memory files, and around ten are anticipatory entries based on domain knowledge rather than prior incidents — those are flagged inline. The whole list remains in draft and needs review before any push to the Dolibarr KM module via API.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Manufacturing Orders (MO).

So, what is a Manufacturing Order? Think of it as the central document that schedules and tracks a production run. When your business needs to make something, a Manufacturing Order is what kicks that process off. It pulls together your components, tells the system what you’re building, how much of it you’re building, and then tracks the whole thing from start to finish. As production happens, it consumes stock from your component inventory and, when everything’s done, it adds the finished goods back into your warehouse. That loop — components go in, finished product comes out — is what a Manufacturing Order manages.

Let’s walk through the lifecycle of a Manufacturing Order, because understanding the stages really helps you see how the whole thing fits together.

It starts in Draft. This is where you’re setting things up. You haven’t committed to anything yet — you’re just putting the order together, specifying what you want to produce and in what quantity. Think of it as your planning stage.

Once you’re happy with it, you move the order to Validated. At this point the system recognises the order as real and approved. You’re saying, yes, this production run is happening.

From there, it moves into the In Production stage. This is the active phase — work is underway, components are being consumed, and you’re recording progress as things get built.

Then comes Completed. The production run is done. The finished goods exist.

And finally, Stock Updated. This is where the system catches up with reality — your finished goods are added to inventory, and the components that were used are deducted from stock. The books reflect what actually happened on the floor.

So that’s five stages: Draft, Validated, In Production, Completed, and Stock Updated. Each one represents a meaningful checkpoint in the production process.

Now let’s talk about how you actually work with a Manufacturing Order day to day.

The first thing you do is create the MO from a Bill of Materials, which you might hear referred to as a BOM. A Bill of Materials is essentially the recipe — it lists every component you need and in what quantity to produce the finished item. When you create a Manufacturing Order, you reference that BOM and specify how many units you want to produce. The system uses that information to work out exactly what stock it needs to pull.

Next, you check and reserve your component stock. Before you can actually build anything, you need to know the materials are available. The system lets you verify that the components are on hand and reserve them so they’re earmarked for this production run and not accidentally allocated elsewhere.

After that, you record production progress as work happens. This keeps the system up to date in real time, so your inventory and production data stay accurate throughout the run rather than only at the end.

And finally, when the run is done, you complete the MO. That’s the action that triggers the finished goods being added to stock — closing the loop we talked about earlier.

There are a few related areas you’ll want to be familiar with alongside Manufacturing Orders. The Bill of Materials is the starting point for every MO, so understanding how BOMs are structured is essential. Stock and Warehouse Management ties in closely, since every MO both draws from and contributes to your inventory. And if you’re tracking the cost side of things, the Margins module connects to MOs for production cost tracking — useful for understanding how profitable each production run actually is.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Payment Platforms Integration.

So let’s start with the big picture. When NZRT works with clients and needs to collect payment online, there’s one platform handling all of that — and that platform is PayPal. That’s the only online payment method NZRT currently uses, and it covers the two most common ways a customer might want to pay: through their PayPal wallet directly, or by entering a card. So whether your customer has a PayPal account or not, the checkout experience still works for them.

Now, you might wonder why just one platform. Keeping things simple has real advantages. One integration to maintain, one place to check transaction history, one set of credentials to manage, and one reconciliation process when it comes to your books. For a consultancy like NZRT, that simplicity keeps overhead low and reduces the number of things that can go wrong.

Let’s walk through exactly how the payment flow works from end to end, because it’s worth understanding each step clearly.

It all starts with an invoice. When NZRT raises an invoice for a client — whether that’s for consulting work, a project deliverable, or any other service — that invoice gets a button embedded in it. You’ll see it labeled something like “Pay online.” That button is the entry point for the entire payment process. The customer doesn’t need to navigate anywhere else or look up bank details. The call to action is right there in the invoice itself.

When the customer clicks that button, they get taken directly to a PayPal payment page. This is where they complete the transaction. If they have a PayPal account, they can log in and pay from their balance or a linked funding source. If they don’t have an account, they can still pay by entering their card details directly on that page. PayPal handles all of the secure processing at that point — NZRT’s systems aren’t touching card data at all, which is a significant compliance and security benefit.

Now here’s the part that makes this integration really useful from an operational standpoint. Once the payment goes through and PayPal confirms it, the invoice in Dolibarr — which is NZRT’s ERP system — gets automatically marked as paid. You don’t need to go in manually and update anything. The status change happens on its own. That means your accounts are staying current in real time, and you’re not relying on someone remembering to tick a box after a payment notification comes in.

This three-step flow — invoice raised, customer pays via PayPal, invoice auto-updated — is clean and low-friction for everyone involved. The customer gets a familiar, trusted payment experience. The finance team gets automatic reconciliation. And there’s a clear audit trail through both PayPal’s transaction records and the invoice status in Dolibarr.

If you’re working in the finance or client management side of NZRT, it’s worth knowing how this connects to the broader sales workflow. The Payment Platforms Integration sits within the Customer and Sales area of the wiki, which means it ties into how invoices are created, how clients are managed, and how revenue is tracked. If you’re troubleshooting a payment issue — say, a customer says they paid but the invoice hasn’t updated — the first place to check is PayPal’s transaction records on that end, then look at whether the Dolibarr integration received the confirmation signal correctly.

It’s also worth noting the status of this integration. As of the last update to this documentation, PayPal is marked as active. There are no other payment platforms listed as planned or in progress right now. So if you’re ever asked whether NZRT supports Stripe, direct bank transfer through an online portal, or any other payment method — the current answer is no, not through an integrated online flow. Any other payment arrangements would be handled outside this system.

One more practical point: because the pay button is embedded in the invoice itself, the quality of that invoice matters. If the invoice isn’t generated correctly, or the integration isn’t configured to embed the button, the customer won’t have a direct path to pay online. If you ever notice a client hasn’t paid and you want to confirm they had a working payment option, check that the invoice was issued with the button properly embedded. That’s your first diagnostic step before chasing the client or assuming there’s a payment issue on their end.

So to recap what you’ve learned today: NZRT uses PayPal as its single online payment platform. It supports both PayPal wallet and card payments. The flow is straightforward — invoice out, customer clicks pay, PayPal processes it, invoice auto-marks as paid. It’s integrated with Dolibarr, it’s currently active, and it keeps the payment process simple for both clients and the internal team.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Purchase Orders, or POs as we tend to call them day to day.

So what is a Purchase Order? At its core, a Purchase Order is a formal order you send to a supplier. It’s the document that kicks off the buying process on your end. Once a PO is in play, it does two important things downstream. First, it triggers the goods reception process, so when your delivery arrives you have something to match it against. Second, once that delivery happens, it generates the supplier invoice for you automatically. That tight link between ordering, receiving, and invoicing is what makes Purchase Orders such a central piece of the procurement workflow in Dolibarr.

Now let’s talk about the lifecycle of a Purchase Order, because understanding where a PO sits at any given moment tells you exactly what can and can’t happen next. The wiki shows this as a flow through six stages, so let me walk you through each one.

It starts as a Draft. This is your working document. Nothing has been committed yet. You’re pulling together the supplier, the line items, quantities, prices. Think of it as your scratchpad before anything official happens.

From Draft, a PO moves to Approved. This is where a sign-off happens. Depending on how your approval workflow is configured, this might happen automatically for low-value orders or it might require a manager to manually approve it when the order value crosses a certain threshold. More on that in a moment.

Once approved, the PO moves to Sent. This means the order has gone out to the supplier. They know what you want and when you want it.

Here’s where it gets interesting. When goods start arriving, the PO can enter a Partially Received state. Not everything has to arrive at once. If your supplier sends you half the order today and the rest comes next week, Dolibarr handles that gracefully. You receive what arrived, and the system keeps track of what’s still outstanding. That outstanding portion becomes a back-order that stays on the PO until it’s fulfilled.

Once everything has arrived, the PO moves to Fully Received. That’s your confirmation that everything you ordered has come through the door.

And finally, the last stage is Invoiced. At this point the supplier invoice has been generated and the financial side of things is locked in.

So that’s the six stages: Draft, Approved, Sent, Partially Received, Fully Received, and Invoiced. Each stage is a checkpoint that keeps your procurement process structured and auditable.

Now let’s look at the key features that make Purchase Orders in Dolibarr genuinely useful.

First up is multi-currency support. If you’re buying from international suppliers, you can raise a PO in the supplier’s currency. You don’t have to manually convert everything back to your home currency before you enter it. The system handles that.

Second is the approval workflow, and this one is worth pausing on. You can configure thresholds so that smaller orders go through automatically while larger ones require explicit approval before they move forward. This gives you financial controls without creating unnecessary friction for routine purchases.

Third is partial reception and back-order tracking. You already heard this touched on in the lifecycle walkthrough. The point is that you don’t have to wait for a complete delivery to start processing what’s arrived. You can receive in stages, and the system keeps a running tally of what’s still due. That’s especially handy when you’re dealing with suppliers who ship in batches or when lead times are unpredictable.

Fourth is automatic stock updates on reception. When you mark goods as received against a PO, your stock levels update automatically. You don’t have to go into a separate stock module and manually adjust quantities. The reception event does that work for you in the background. This keeps your inventory accurate in real time.

Those four features together mean that a Purchase Order isn’t just a piece of paperwork. It’s a live document that drives actions across multiple parts of the system.

Finally, it’s worth knowing how Purchase Orders connect to other areas of Dolibarr. When goods arrive, that flows into Delivery and Reception. Once the PO is fully or partially received, it ties into Supplier Invoices and Credit Notes, which is where the financial reconciliation happens. And as we just mentioned, the reception event feeds directly into Stock. So if you’re working in any of those areas and something looks off, it’s often worth tracing back to the originating Purchase Order to understand where things stand.

That’s the full picture of Purchase Orders in Dolibarr. From raising a draft all the way through to invoicing, the PO is the thread that connects your supplier relationship to your internal receiving and financial processes.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at WordPress Integration.

This episode covers how WordPress and Dolibarr connect inside the NZRT setup, so if you work with either of those systems — or you’re just curious about how the pieces fit together — stick around.

First, a bit of context. NZRT runs two WordPress sites. One is the ICS site — that stands for Internet Consulting Services — and this is the site that actually integrates with Dolibarr. Through that integration, products, clients, and orders managed in Dolibarr can surface on the ICS site. The second site is the NCS site, which handles NZRT Charitable Services, and that one sits completely separately — it doesn’t talk to Dolibarr at all.

So how does the integration actually work? There are two main methods.

The first and primary method is what’s called the Agent REST API approach. AI agents call both the Dolibarr REST API and the WordPress REST API independently, using a set of tools provided by the NZRT MCP server. Think of it as an orchestration layer — Claude or the run-dot-py agents sit in the middle and coordinate cross-system operations. For example, if you need to sync a product from Dolibarr and publish it to WordPress, an agent can handle each side of that through dedicated tools. On the Dolibarr side you have tools for getting and creating products, and on the WordPress side you have tools for creating and updating posts. The Operating Model documentation goes deeper on the MCP server setup if you want to follow up.

The second method is an Obsidian-to-WordPress publishing flow. Vault notes written in Obsidian can be published directly to the ICS WordPress site using the obsidian-wordpress plugin. Simple and straightforward.

Now let’s look at something a bit more technical — the Bridge Plugin and Webhook Trigger setup. This is used specifically for NZRT intake forms, and it enables a direct connection from WordPress straight into Dolibarr. Here’s how that flow works when someone submits a form on the WordPress side.

The form submission triggers an AJAX call that passes through WordPress’s admin handler. That kicks off a function inside a custom plugin called the nzrt-dolibarr-bridge. That function then makes a request to Dolibarr’s REST API, targeting the thirdparties endpoint and passing the API key as a header. Dolibarr receives that, creates the thirdparty record, and internally fires what’s called a company-create action. Now, on the Dolibarr side, there’s a second custom file called the nzrt webhook trigger, sitting inside Dolibarr’s custom triggers folder. It checks whether the company-create action appears in a global setting called WEBHOOK_EVENTS. If it does, it fires off a signed JSON payload to a configured webhook URL, attaching two custom headers — one containing an HMAC-SHA256 signature and one identifying the event type. That signature is what lets the receiving end verify the request is genuine.

Two files make all of this work. The bridge plugin file lives in the 000WOR repository and is deployed to WordPress as a plugin. The webhook trigger file lives in the 000DOL repository and is deployed inside Dolibarr’s custom triggers folder.

To get this running, you also need three configuration constants set up inside Dolibarr — you’ll find these under Setup, then Other, then Constants. There are three of them to know about. The first is WEBHOOK_URL, which is the endpoint Dolibarr will post the event payload to. The second is WEBHOOK_SECRET, which is the signing key used to generate that HMAC-SHA256 signature on outgoing payloads. The third is WEBHOOK_EVENTS, which is a comma-separated list of the action codes you want to trigger webhooks — so for example, you might include both company-create and company-modify if you want events fired for both scenarios.

If you need to set any of this up from scratch, there’s a separate NZRT Integrations document that walks through the deployment steps in detail. And if you’re looking at the broader picture — like what modules are available or how WordPress service codes fit into the NZRT taxonomy — check out the Module List and NZRT WordPress Service Codes docs linked from the related section of this wiki page.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Ticket Categories & Types.

If you’ve ever wondered how the eight NZRT virtual agents know what to do and when to do it, the answer is Dolibarr tickets. Dolibarr is the ERP platform NZRT uses as its primary work-assignment layer, and every agent task — whether that’s posting to the forum, writing a blog summary, handling a charitable services intake, or running a system operation — flows through a Dolibarr ticket. Nothing gets actioned without one.

So let’s break down how those tickets are structured, starting with type codes.

A type code tells you the nature of the work being requested. There are five of them. The first is called FORUM POST, and it means the assigned agent needs to post a discussion or comment to the Flarum community forum. The second is WIKI BLOG, which is specifically for PAM — the Products and Marketing agent — to write a plain-English summary post to the WordPress agent blog. Think of it as turning internal wiki content into something readable for a wider audience.

The third type code is NCS, which stands for NZRT Charitable Services. This one covers beneficiary intake, follow-up, and service delivery for the charitable arm of the organisation. Fourth is ICS INTAKE, which handles client intake for Internet Consulting Services. And fifth is simply GENERAL — a catch-all for system operations, one-off jobs, and anything that doesn’t fit neatly into the other four categories.

Now let’s talk about how tickets get routed to the right agent. Each of the eight virtual agents has a named category in Dolibarr, and when a ticket is created, it gets assigned to the correct agent using their Dolibarr user ID. There are eight agents in total. CAS handles Customer and Sales, and has user ID four. DAI covers Data and Analytics, user ID nine. DAN looks after Database and Systems, user ID ten. EMA handles EDM — electronic direct mail — user ID eight. FIN is Finance, user ID six. HAN covers Human Resources, user ID seven. PAM is Products and Marketing, user ID three. And SUN handles Supplier and Purchasing, user ID five.

So when you see a ticket assigned to user ID three, you know that’s PAM’s work. When you see user ID ten, that’s DAN. The category label on the ticket — for example, PAM — Products and Marketing — reinforces the routing alongside that numeric assignment.

There’s also a special category of tickets used for TOGAF ADM work. TOGAF is the architecture framework NZRT uses for enterprise planning, and it runs through a series of phases. For each phase, there are eight specialist ticket categories — one per agent domain — matching the scope of that phase. So if you’re in a migration planning phase, each agent gets a ticket relevant to their domain within that phase. These tickets are created automatically by a script called create togaf phase tickets dot py, so you don’t need to worry about building them by hand.

Speaking of scripts — and this is important — tickets at NZRT are never created manually. They’re always created by Claude or by automation scripts. Specifically, the create-ticket scripts live in the zero zero zero AGT repository. There’s a different script for each work type: one for CLA session traceability, one for WordPress posts, one for forum posts, one for wiki-to-blog summaries, and so on. You match the script to the work type.

One more thing worth knowing about credentials: when tickets need to be created across multiple agents — say, spinning up eight TOGAF tickets at once — the xc admin API key must be used. If you use an individual agent’s API key instead, that agent will only be able to see the tickets assigned to them. So for cross-agent creation, admin key only.

Finally, there are ticket tags. These are a secondary grouping layer in Dolibarr, separate from the project categories. You’ll see tags like NCS for charitable services work, wiki-summary for blog conversion tasks, and togaf for architecture phase work. There are also system tags — things like win for Windows operations, git for GitHub work, llm for language model tasks, wor for WordPress, dol for Dolibarr, ncl for Nextcloud, fla for Flarum, and cpl for cPanel. These tags let you filter and group tickets by system or topic without relying solely on the agent assignment or type code.

So to summarise what you’ve just heard: every agent task starts as a Dolibarr ticket. The type code tells you what kind of work it is. The agent category and user ID tell you who does it. TOGAF phases get their own specialist tickets generated automatically. Scripts do the creating — never manual entry. And tags give you a flexible secondary layer for grouping by system or topic.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Ticket System (Help Desk).

If you’ve ever wondered how NZRT keeps track of customer support requests, agent tasks, and everything in between, the answer is the Dolibarr ticket system. It’s a centralised help desk that combines support ticketing, a knowledge base, SLA tracking, and email integration all in one place. Let’s walk through how it all works.

First, let’s talk about the lifecycle of a ticket. When a ticket is first created, it starts in a New state. From there, it gets Assigned to someone — or in NZRT’s case, to one of the virtual agents. Once work begins, the ticket moves to In Progress. If the agent or system is waiting on a response from a customer or another party, the ticket shifts to a Pending Customer state. When the issue is sorted, it gets marked as Resolved, and once everything is confirmed and wrapped up, it closes out completely. So you’ve got six clear stages: New, Assigned, In Progress, Pending Customer, Resolved, and Closed — and every ticket flows through that chain.

Now, when it comes to key features, there are four main things you’ll want to know about. The first is priority levels. Every ticket you create gets assigned one of four priority levels — low, normal, high, or urgent — so whoever is handling it knows exactly how quickly they need to act. Second is email-to-ticket functionality. Through something called the Email Collector, incoming emails can automatically generate tickets in the system. That means if a customer sends a message to a support address, a ticket gets created without anyone needing to do it manually. Third is the knowledge base. The ticket system ties into a library of articles that can help resolve common issues — useful both for agents handling tickets and for customers looking for self-service answers. And fourth is SLA tracking. SLA stands for Service Level Agreement, and the system monitors both response time and resolution time to make sure tickets are being handled within agreed timeframes.

Now let’s look at how NZRT actually uses this system, because it goes a bit deeper than a typical help desk setup. At NZRT, the ticket system is the primary way work gets assigned to all eight virtual agents. When Claude — the AI coordinating the operation — needs to assign a task, it creates a ticket through the Dolibarr REST API using a set of Python scripts. There are different versions of these scripts depending on the type of work being assigned.

Each ticket carries a type code that tells the system what kind of work it involves. For example, there are type codes for forum posts, wiki-to-blog summaries, charitable services work, consulting intake tasks, and general work items. Alongside that type code, each ticket specifies which agent it’s assigned to using an assignment field that links directly to the agent’s user account in the system. Tickets can also be linked to specific Dolibarr projects, which keeps everything organised by initiative or deliverable.

Once a ticket is created and assigned, the relevant agent reads it, carries out the work, and then closes the ticket programmatically — meaning the whole loop from creation to completion can happen without any manual intervention.

One important detail about permissions: the API key used to create tickets matters a lot. Standard agent API keys will only return tickets that are assigned to that particular agent. If you need to create tickets on behalf of multiple agents — or view tickets across the whole system — you need to use the cross-agent admin API key. That key belongs to the xc admin account, and it’s what Claude uses when coordinating work across all eight agents.

The ticket system also connects to two other areas worth being aware of. One is Interventions, which is how manual or escalated actions get recorded in Dolibarr. The other is the Email Collector, which handles inbound email routing and turns those emails into tickets automatically.

So to bring it all together — the ticket system at NZRT isn’t just a customer support queue. It’s the backbone of how work gets distributed, tracked, and completed across the entire virtual agent team. Every task has a ticket, every ticket has an owner, and every owner has a clear status to move through until the work is done.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at Users & Groups.

In Dolibarr, the system NZRT uses to manage projects, invoices, and everything in between, user accounts are tied to fine-grained permissions. That means each user or agent only gets access to the specific modules and actions they actually need. NZRT takes this seriously — there are no shared accounts. Every agent has their own dedicated login.

When we say agents here, we mean NZRT’s virtual AI agent accounts. These are real Dolibarr user accounts, one per agent, set up so that each AI can interact with the system in a controlled and traceable way. They authenticate using individual API keys rather than a traditional username and password flow. The passwords do exist, but they’re randomly generated and stored securely in the Nextcloud shared credentials folder — not something you’d ever type in manually.

Let’s walk through the agent roster. There are nine accounts in total, and the table in the wiki gives you the agent code, their Dolibarr user ID, their login handle, display name, email address, the modules they can access, and their current status.

First up is xc, the admin account, with a Dolibarr ID of 2. This account displays as XC Admin and uses the admin email address. XC has access to all modules — it’s the top-level account.

Next is cas, ID 4, the Sales agent. CAS has access to Thirdparties, Proposals, and Orders — covering the client-facing sales pipeline.

Then there’s dai, ID 9, the Data agent. DAI has read access to exports plus access to accounting results. It’s a deliberately limited account — read-only on the export side.

DAN is ID 10, the DBA agent. Interestingly, DAN has no Dolibarr module permissions at all — DAN operates exclusively through Nextcloud. So this account exists in the system but is intentionally restricted on the Dolibarr side.

EMA is ID 8, the document and email management agent. EMA has access to ECM, which is the electronic content management module, plus Mass Emailing and Export.

FIN is ID 6, the Finance agent. FIN covers Invoices, Bank, and Accounting — the core financial stack.

HAN is ID 7, the HR agent. HAN covers the HRM module, Leave, and Expenses — everything to do with people management.

PAM is ID 3, the Products agent. PAM handles Products, Stock, and Manufacturing — the inventory and production side of the business.

Finally, SUN is ID 5, the Purchasing agent. SUN covers Suppliers, Purchase Orders, and Delivery.

So that’s nine accounts in total: xc, cas, dai, dan, ema, fin, han, pam, and sun.

All of these accounts were provisioned on the twenty-first of April 2026 using a script called create agents, which ran directly against the database. Then two days later, on the twenty-third of April, module permissions were applied using a script called set dolibarr permissions. That run set 58 individual permissions across seven of the agents — all done in a single automated pass.

On the topic of permissions, the wiki notes there are four levels to understand: Read, Write, Delete, and Admin. These are the four tiers that Dolibarr uses to control what any given user can actually do within each module. So an agent might have read access to a module but not write access — or write access but not the ability to delete records or change admin-level settings. The detail of exactly which agents hold which permission levels is covered in a separate Security and Permissions article, which is worth reading alongside this one.

One last thing worth noting is the API access model. When NZRT’s AI agents actually call Dolibarr to do work — creating tickets, updating projects, fetching data — they use the REST API directly, and each agent has its own API key configured for that purpose. The keys are set up separately from the account provisioning step, as part of the process of wiring each AI agent into the live system.

If you want to dig deeper, the related articles to check out are Security and Permissions for the full permission breakdown, and the Agent Account Setup guide for the step-by-step provisioning process. There’s also an Employees article if you’re looking at human user accounts rather than the virtual agent accounts covered here.

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