Tag Archives: ncs

000DOL, 09 - Integrations

Ncs Intake Workflow

Welcome to the NZRT Wiki Podcast. Today we’re looking at NCS Intake Workflow.

So what is the NCS Intake Workflow? Put simply, it’s the end-to-end process that takes a charitable services application from the NZRT public website all the way into the Dolibarr ERP system. Let’s walk through exactly how that happens.

It all starts with a trigger. A charitable entity or community group visits the intake form page on the NZRT website. The page lives at the NCS intake address on nzrtnetwork.com. One thing worth knowing is that this page is a standalone PHP file, not a WordPress plugin. That was a deliberate choice, made for speed and simplicity.

Now, when someone fills in that form, they’re providing four pieces of information: their organisation name, their email address, their phone number, and a message describing their situation or need. Once they hit submit, the automated process kicks in.

The PHP handler that sits behind the form does two important things almost simultaneously. First, it creates a new thirdparty record in Dolibarr. Think of a thirdparty as Dolibarr’s way of representing an external organisation. The record gets tagged with a type that identifies it as an NCS entity, and it receives a unique client code that combines the letters NCS, the organisation name, and a timestamp so you can always trace when that record was created.

Second, that same PHP handler creates a support ticket in Dolibarr and assigns it to an agent called cas. The ticket gets categorised under NCS, it’s linked to the relevant NCS project inside Dolibarr, and it’s tagged so it shows up correctly in all the right views. So by the time the form submission is complete, you’ve got both an organisation record and a live support ticket waiting in the system.

The fourth automated step is an email notification. Nathan, the person responsible for reviewing these applications, receives an email with the subject line NCS Application followed by the organisation’s name, and it includes a summary of what was submitted along with delivery instructions.

That brings us to the manual review stage. Nathan reads the application email and decides whether it’s a good fit. If he’s happy with it, he replies with the word APPROVED followed by the word services. If the application isn’t suitable, there’s no automated reply needed — that gets handled manually on a case-by-case basis.

Once Nathan sends that approval reply, the automated delivery process takes over. A script called mail handler dot py is watching for exactly that kind of reply. When it detects Nathan’s approval, it triggers another script called cas NCS delivery dot py. That script is responsible for sending the applicant the GitHub repository ZIP files they need by email.

Now let’s talk about how the form fields map across to Dolibarr, because that’s a useful thing to understand. There are four form fields and here’s where each one ends up. The organisation name feeds into both the main name field on the thirdparty record and into that client code prefix we mentioned earlier. The email address maps directly to the email field. The phone number maps to the phone field. And the message the applicant writes goes into a private note on the thirdparty record, so your team can see it internally but the applicant won’t see it reflected back to them.

Finally, there are a couple of escalation rules to be aware of. If an applicant goes quiet and there’s been no response after three contact attempts spread across seven days, the thirdparty record gets marked as Cold and the ticket gets closed. That keeps your queue clean and avoids things sitting open indefinitely. The other rule covers schools and large institutions — if an application comes in from one of those, you defer it. They’re considered out of scope for the near-term NCS programme, so they don’t get processed through the same flow.

And that’s the full picture. A form submission on the website kicks off an automated chain that creates both an organisation record and a support ticket in Dolibarr, notifies Nathan by email, waits for his approval, and then automatically delivers the relevant resources to the applicant. The only human decision in the whole workflow is Nathan’s approval reply, and everything else is handled for you.

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

000WOR, 10 - NCS Website

Ncs Intake Form

Welcome to the NZRT Wiki Podcast. Today we’re looking at NCS Intake Form.

The NCS Intake Form is the public-facing form on the NZRT website that charitable services applicants use to get in touch. It’s powered by the nzrt-dolibarr-bridge WordPress plugin, and the whole point of it is to save time — when someone submits the form, everything gets created in Dolibarr automatically. No one on the NZRT side has to manually enter anything.

So how do you get the form onto a WordPress page? You use a shortcode. Shortcodes in WordPress are small pieces of text you drop into a page or post, and WordPress replaces them with actual content when the page loads. The shortcode for this form is simply the words nzrt intake form wrapped in square brackets. Place that on any WordPress page and the form appears, ready to go.

Now, one thing worth knowing about how this form works under the hood — it uses something called AJAX. That means when a visitor hits Submit, the page does not reload. The form submits silently in the background and the user just sees a thank-you message appear right there on the page. It’s also nonce-protected, which is a WordPress security mechanism that prevents certain types of cross-site request forgery attacks.

Let’s walk through the full technical flow from the moment someone clicks Submit. First, the visitor fills in the form and submits it. Second, JavaScript sends the form data behind the scenes to a WordPress endpoint, triggering an action called nzrt intake submit. Third, on the PHP side, the nonce gets validated to confirm the request is legitimate, and then the form data is sent to the Dolibarr API to create a new thirdparty record — that’s Dolibarr’s term for a contact or organisation. Fourth, Dolibarr responds with an ID for that newly created thirdparty. Fifth, a second API call goes out to create a support ticket in Dolibarr, filed under the NCS charitable services category and linked to that thirdparty. Sixth, PHP sends an email to Nathan with a summary of the application. And seventh, the user sees a thank-you message on the page — no redirect, no wait.

Now let’s talk about what the form actually collects. There are four fields. The first is Organisation Name, which maps to the name field in Dolibarr. The second is Email, which maps to the email field. The third is Phone, which maps to the phone field. And the fourth is Message, which gets stored as a private note on the thirdparty record in Dolibarr. Private notes in Dolibarr are internal-only — they’re not visible to the applicant.

In terms of setup, the plugin file is called nzrt-dolibarr-bridge dot php and it lives in the 000WOR repository. To configure it, you go to WP Admin, then Settings, then Dolibarr Bridge. There you set two things: the API URL, which points to the Dolibarr installation, and the API key that authorises the connection. There’s also a product sync option in there, but that’s optional and not required for the intake form to work.

What happens after someone submits? Nathan receives the email summary and reviews the application manually. If he wants to approve it, he replies to that email with the words APPROVED colon services. That reply triggers the automated delivery pipeline — specifically two scripts called mail handler dot py and cas ncs delivery dot py — which handle the next steps in fulfilling the charitable services request. The full details of that post-submission process are documented separately in the standard operating procedure called SOP-NCS-001, so if you need to follow that through end to end, that’s where to look.

To summarise what you’ve learned today: the NCS Intake Form is a WordPress shortcode-driven form that collects basic organisation details from charitable applicants. It submits via AJAX with CSRF protection, automatically creates a Dolibarr thirdparty and support ticket, and fires off a notification email to Nathan. Configuration lives in WP Admin under the Dolibarr Bridge settings, and the plugin is managed in the 000WOR repo. The form is designed so that nothing falls through the cracks — every submission leaves a clean record in the ERP system without any manual data entry.

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