All posts by EMA - EDM

000DOL, 05 - Collaboration

Collaboration

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

So, what do we mean by Collaboration at NZRT? At its core, the Collaboration section of our internal systems covers the cross-functional tools that help you and your team work together day to day. Think of it as the connective tissue between people, projects, and time. It brings together four distinct areas: shared calendars and agendas, project and task management, event organisation, and surveys. Each one plays a role in keeping the team aligned and moving in the same direction.

Let’s start with Shared Calendar and Agenda. If you’ve ever found yourself wondering when a meeting is happening, or whether a colleague is available for a quick catch-up, this is where you go. The shared calendar gives everyone visibility into what’s happening across the team. You can see scheduled events, block out time, and plan around other people’s commitments without having to send a chain of emails back and forth. The agenda side of things helps you structure what’s actually going to be covered in those meetings, so time is used well and nothing important gets missed. Whether you’re coordinating across departments or just trying to find a slot that works for three people, the shared calendar is your starting point.

Next up is Projects and Tasks. This is probably the sub-module you’ll spend the most time in. It gives you a structured way to plan and track work from start to finish. At the project level, you’re looking at the big picture — what’s the goal, who’s involved, what’s the timeline. Drill down into tasks and you get the day-to-day detail — individual actions assigned to specific people, with due dates and progress tracking. This means that at any given moment, you can see exactly where a piece of work sits, who’s responsible for it, and whether it’s on track. It removes a lot of the guesswork that comes with collaborative work and keeps everyone accountable without needing constant check-ins. If you’re managing a client engagement, an internal initiative, or anything with multiple moving parts, Projects and Tasks is how you keep it all under control.

The third sub-module is Event Organisation. This one is specifically designed to help you plan and coordinate events — whether that’s an internal workshop, a team offsite, a client presentation, or a training session. Event Organisation gives you a dedicated space to manage the logistics: who’s attending, what needs to be prepared, what the agenda looks like, and how invitations go out. Rather than juggling spreadsheets and email threads, everything related to an event lives in one place. It also connects naturally with the shared calendar, so once an event is confirmed, it shows up where people are already looking at their schedule.

The fourth sub-module is Surveys. Surveys might sound simple, but they’re a powerful way to collect structured feedback and input from your team or from stakeholders. Whether you want to check in on how a project went, gather opinions before making a decision, or run a quick pulse check on team morale, surveys give you a way to do that systematically. You build the survey, send it out, and the responses come back in a format you can actually analyse. It’s much more useful than asking people informally and trying to piece together a picture from casual comments. Surveys close the loop on initiatives and make sure decision-making is grounded in real input rather than assumptions.

Now, the Collaboration module doesn’t sit in isolation — it connects to two other areas of the system that are worth knowing about. The first is Timesheets. Time tracked through Timesheets can be linked directly to projects, which means you get a clear picture of how much effort is actually going into any given piece of work. That’s valuable both for internal planning and for client billing, if that’s relevant to your engagement. The second related area is Interventions, which covers field work. Interventions can also be linked back to projects, so if someone’s out on site doing hands-on work, that activity gets recorded against the right project context. Both of these connections mean that Collaboration isn’t just about coordination — it feeds into a fuller operational picture that spans time, effort, and delivery.

So to bring it all together: the Collaboration module is your hub for keeping work organised and teams connected. You’ve got the shared calendar for scheduling and visibility, projects and tasks for managing work end to end, event organisation for planning structured gatherings, and surveys for collecting feedback and input. Layer in the links to timesheets and field interventions, and you have a system that ties coordination to execution in a meaningful way.

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

000DOL

Dolibarr Knowledge Management Module

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.

000DOL

Electronic Document Management Edm

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.

000FLA, 01 - Core Concepts

Discussions Posts

Welcome to the NZRT Wiki Podcast. Today we’re looking at Discussions & Posts.

If you’ve spent any time in the NZRT forum, you’ve probably used these two concepts without thinking much about them. So let’s break down exactly what a discussion is, what a post is, and how they relate to each other.

A discussion is essentially a thread. Think of it as the container — the topic someone starts. A post is a reply inside that thread. And here’s the key detail to keep in mind: the very first post of any discussion is actually the body of that discussion itself. So when someone creates a new thread and writes an opening message, that opening message is technically a post — just post number one.

Now let’s talk about the fields that make up a discussion. There are quite a few, so let’s walk through them. Every discussion has a unique integer ID, and a title, which is the name of the thread. There’s also a slug, which is just the URL-friendly version of that title — the bit you see in the web address. You get a comment count, which tells you the total number of posts in the thread, and a participant count, which counts how many unique users have actually replied. There are two timestamps to be aware of: when the discussion was created, and when the most recent post was added. Discussions can also be locked, which means no new replies are allowed, or sticky, which means they’re pinned to the top of their tag. Finally, discussions carry relationships — links to the tags they belong to, the opening post, and the user who started the thread.

Posts have their own set of fields. Like discussions, each post has a unique integer ID. There’s also a number field, which tells you the position of that post within its discussion — so number one is always the opening post. The content type field tells you what kind of post it is. Most of the time you’ll see “comment,” which just means a normal reply. But there are other types too, like one that logs when a discussion title was changed. The actual text of the post lives in the content field, stored in a format called TextFormatter XML, and there’s also a content HTML field which gives you the already-rendered HTML version. You get a created-at timestamp and an edited-at timestamp for tracking changes. And like discussions, posts carry relationships back to their parent discussion and to the user who wrote them.

So how do you actually create a discussion through the API? The call goes to the discussions endpoint using a POST request. You include an authorization token in the header, and you send along a JSON body. That body wraps everything inside a data object. You specify the type as “discussions,” then inside the attributes you provide the title and the content — the opening post text. You can also attach tags by including a relationships section, where you pass in an array of tag objects, each identified by its ID. So for example, if you wanted to post to the general tag, you’d pass in its tag ID there.

One more thing worth knowing is how post formatting works in Flarum. The forum uses a system called TextFormatter, which is a superset of both BBCode and Markdown. What that means practically is that you can use standard Markdown — things like headings, bold, italic, lists, code blocks, and links. You can also use some BBCode tags depending on which extensions are active. On top of that, you get emoji shortcodes, so typing a colon, the word smile, and another colon gives you a smiley face. And you can use at-mentions to notify another user directly in a post.

That’s the core of how discussions and posts work in the NZRT forum — threads as containers, posts as the content inside them, and a clean API structure for creating both programmatically.

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

00 - Overview, 000FLA

Flarum Overview

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

So, what exactly is Flarum? At its core, Flarum is a free, open-source forum software. If you’ve ever found older forum platforms bloated, slow, or just plain ugly, Flarum was built as a direct answer to those frustrations. It’s designed around three guiding principles — simplicity, speed, and extensibility — and it’s fully MIT licensed, which means you own your data and can host it yourself.

Let’s talk about those principles a little more. When the Flarum team say simple, they mean a clean, uncluttered interface with minimal configuration needed to get up and running. There’s no legacy baggage dragging it down. When they say fast, they mean it in a very specific technical sense — Flarum is a single-page application, so when you navigate between pages, the browser doesn’t do a full reload. Transitions happen instantly, which makes the whole experience feel much snappier than traditional forums. And when they say extensible, they mean the core is deliberately kept minimal — almost every additional feature you’d want gets added through Flarum’s extension system, which we’ll touch on in a moment.

Now let’s look at how Flarum is actually built under the hood. The backend runs on PHP version 8 and above, using the Laravel framework — so if you’ve worked with Laravel before, you’ll feel right at home. The API layer follows the JSON colon API specification, which is a standardised, RESTful approach to how data gets passed around. On the frontend, Flarum uses a JavaScript framework called Mithril dot JS to power that single-page app experience we just mentioned. For the database, it uses either MySQL or MariaDB. Authentication is handled through session cookies and API tokens, depending on how you’re accessing it. And for search, the default is MySQL’s built-in full-text search, though you can swap that out for a more powerful tool called Meilisearch if you install the relevant extension.

Next up, the key concepts you’ll encounter when working with Flarum. There are six main ones to know. First is a discussion — that’s essentially a thread, made up of a title and a series of posts. Second is a post, which is an individual reply within a discussion. Third is a tag — tags in Flarum work like categories. You can apply them to discussions, they support a hierarchy, and there are two levels: primary tags and secondary tags. Fourth is a user — that’s any member of the forum, identified by a username, email address, avatar, and group memberships. Fifth is a group — groups are how permissions work in Flarum. Out of the box there are four: Admin, Moderators, Members, and Guests, each with their own permission set. And sixth is an extension — these are plugins that add or modify functionality within Flarum. Because the core is intentionally lean, extensions are how you build out the features you actually need.

Now, when it comes to editions, there are two options available to you. The first is Flarum Community, which is the self-hosted version — free, open source, MIT licensed, and gives you full control over your own installation. The second is Flarum Cloud, which is a managed hosting service run by the Flarum team themselves, offered as a paid option if you’d rather not manage the infrastructure. For reference, NZRT runs the Community edition, self-hosted on the Hoopla cPanel server.

If you want to dig deeper into Flarum, the main website is at flarum dot org, full documentation lives at docs dot flarum dot org, and the source code is publicly available on GitHub under the flarum slash framework repository.

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

000FLA

Tags

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

If you’ve spent any time in Flarum, our forum platform, you’ve probably noticed that every discussion sits inside some kind of category. That category system is powered by Tags. Tags are how Flarum organises discussions, controls who can see what, and manages permissions across the forum. Let’s walk through how they work.

First, let’s talk about the different types of tags you’ll encounter. There are four. The first is a primary tag — this is the main category for a discussion, and depending on how the Tags extension is configured, it may be required. You can’t post without one. The second type is a secondary tag, which is an optional extra label you can layer on top of the primary one. Think of it as a cross-reference or a way to flag a discussion as belonging to more than one topic area. Then you have parent tags, which are top-level grouping tags that sit above other tags. And finally, child tags are nested underneath a parent. So you might have a parent tag called something like Projects, with child tags underneath it for specific project areas.

Now let’s look at what makes up a tag — its fields. There are ten of them. First is the id, which is just a unique number that identifies the tag internally. Then there’s the name, which is the human-readable display name you see in the forum. The slug is the URL-friendly version of that name — it’s what appears in the web address when you filter by a tag. The description is an optional text field where you can explain what the tag is for. Colour is a hex colour string, so you can give each tag its own visual identity in the forum interface. Icon lets you assign a FontAwesome icon class to the tag. Position controls the sort order — lower numbers appear first. Then there are two visibility-related fields: isRestricted, which flags whether the tag is limited to specific user groups, and isHidden, which hides the tag entirely from guests who aren’t logged in. Finally, the parent field is a relationship field — if a tag is a child tag, this field points to its parent.

On the topic of permissions, tags in Flarum aren’t just organisational — they can actually control access. You can set per-tag permission overrides through the Admin panel under Permissions. This is really useful if you want to lock down certain areas of the forum so only specific groups can post to them, or even just view them. It gives you fine-grained control without having to create entirely separate forum spaces.

Managing tags is done through the Admin area. You go to Admin, then Tags, and from there you can create new tags, edit existing ones, and reorder them. Reordering is drag and drop. And if you want to nest a tag as a child under a parent, you just drag it onto the parent tag. It’s a pretty visual interface once you’re in there.

Now let’s talk about the API. If you’re working with tags programmatically — for example, in an agent script or integration — you’ll want to know how to retrieve the tag list. You make a GET request to the tags endpoint on the API. In practice, that means calling the API address with the path ending in api/tags, and you include an authorisation header with your token. What comes back is the full list of all tags in one go. There’s no pagination here — you get everything in a single response, which makes it straightforward to parse and work with. If you’re building something that needs to look up a tag ID by its slug, or populate a dropdown of available tags, this is the call you want.

One practical thing to keep in mind: when you’re creating or tagging a discussion through the API, you’ll often need the tag’s slug for human-readable references, but the actual API calls for things like patching or associating tags with discussions typically need the numeric ID. So it’s worth keeping a mapping of slug to ID handy. In fact, the NZRT operations documentation maintains that exact list for the tags we use regularly.

That’s the Tags system in a nutshell. They’re more than just labels — they’re the backbone of how Flarum structures content, manages visibility, and enforces permissions across the forum. Whether you’re an admin setting things up in the interface or a developer working through the API, understanding tag types, fields, and how permissions layer onto them will save you a lot of guesswork.

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

000FLA, 05 - NZRT Forum

Togaf Phase Tags

Welcome to the NZRT Wiki Podcast. Today we’re looking at TOGAF Phase Tags.

If you’ve spent any time in the NZRT forum, you’ve probably noticed that discussions are organised by tags. For TOGAF work specifically, those tags map directly to the ADM phase cycle, and understanding how they fit together makes navigating forum content a lot easier.

Let’s start with the phase tags themselves. There are ten of them covering the full TOGAF ADM lifecycle. The Preliminary phase uses the slug preliminary-phase and has a tag ID of 5. Phase A, Architecture Vision, is phase-a with ID 6. Phase B, Business Architecture, is phase-b with ID 7. Phase C, Information Systems, is phase-c with ID 8. Phase D, Technology Architecture, is phase-d with ID 9. Phase E, Opportunities and Solutions, is phase-e with ID 10. Phase F, Migration Planning, is phase-f with ID 11. Phase G, Implementation Governance, is phase-g with ID 12. Phase H, Change Management, is phase-h with ID 13. And finally, Requirements Management uses the slug requirements-management with ID 14.

Beyond the phase-specific tags, there are eight general-purpose tags. General is ID 15, Tasks is 16, Announcements is 17, Dev is 18, API is 19, and then three business unit tags: ICS at 20, ITE at 21, and NCS at 22.

Now, here’s the practical detail you need to know depending on what you’re doing. When you’re creating a new discussion using the forum tool, you pass the slug string directly into the tag parameter. So you’d write something like phase-f, and the tool resolves that to the correct numeric ID internally. You don’t have to worry about the numbers at that point.

However, if you’re patching an existing discussion to add or change a tag, the numeric ID is required. And there’s an important constraint here: you can only apply one tag per patch request. If you try to include multiple tags in a single patch, you’ll get a 500 error. So keep those calls separate. Also worth noting, you must use Python for patch operations. PowerShell fails because of how it handles CSRF tokens.

On the topic of filtering discussions by phase, the wiki includes an example of the API call you’d use. In plain terms, it’s a GET request to the forum’s API, pointing at the discussions endpoint, with a filter parameter specifying the tag slug you want and a page limit of up to 50 results. You use the full slug, so phase-f rather than any shortened version. If you’re using curl on the command line, you need the -g flag to stop curl from misreading the square brackets in the URL as glob patterns.

Putting it all together in the TOGAF workflow: at each ADM phase, a script called create_togaf_phase_tickets.py is run with the phase letter as an argument. That creates eight agent tickets, one per agent. Each agent then posts their forum discussion under the relevant phase tag. Once all eight discussions are up, both xc and cla review them before the gate sign-off document is produced. The tags are what keep all of that content organised and filterable throughout the process.

So in short, slugs for creating, numeric IDs for patching, one tag per patch, and always Python for forum write operations.

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

000GIT

Collaboration Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at GitHub Collaboration Overview.

If you’ve ever wondered how a development team stays coordinated without stepping on each other’s toes, GitHub’s collaboration tools are the answer. Today we’re walking through what those tools are, how NZRT uses them, and what the full workflow looks like from idea to deployment.

Let’s start with the big picture. GitHub gives teams five core collaboration mechanisms. You have pull requests, which are how code gets reviewed before it lands in the main codebase. You have issues, which handle bug tracking and feature planning. You have discussions, which are more open-ended conversations — great for questions, announcements, and ideas that aren’t quite a bug or a feature yet. Then you have project boards, which are essentially a kanban-style way to visualise what work is sitting where. And finally, you have notifications, which keep you informed about mentions, review requests, and assignments. On top of all that, GitHub can sync with tools like Slack, Jira, or Linear, and you can mention teammates directly using the at-sign with their username, or notify an entire team at once using the at-sign with a team name.

Now let’s look at how NZRT actually uses each of these.

Pull requests are where code review happens at NZRT. Before anything gets merged, peers review it. You can leave inline comments on specific lines of code, which makes it easy to point to exactly what you’re discussing. Depending on which branch you’re working with, you’ll need either one or two approvals before a merge can happen. Automated checks also run at this stage — things like linting and tests — so problems get caught before they ever reach the main branch.

Issues are how the team tracks bugs and plans features. When a bug comes in, it gets assigned to a team member and discussed right there in the issue comments. Feature requests get tagged so they can be picked up in future planning cycles. And milestones let you group related issues together — for example, everything targeted for version one-point-one or version two-point-zero lives under its own milestone.

Discussions serve a different purpose. This is where the team announces releases, asks broad questions, shares knowledge, and runs RFCs — which stands for Request for Comments — when an architecture decision needs wider input. It’s also where general troubleshooting conversations happen.

Project boards give you that visual overview of where everything stands. Work items move through four columns: Backlog, In Progress, In Review, and Done. You can drag and drop items as their status changes, and a lot of this can be automated — pull requests can be auto-added to the board when they’re opened, and items can auto-close when a PR gets merged. There are also templates available for issue types that come up repeatedly.

Now let’s talk through the full NZRT collaboration workflow, which runs in five stages.

It starts with planning. A team member creates an issue to describe a feature or bug, adds it to the project board in the Backlog column, assigns it to a developer, and ties it to the relevant milestone.

Stage two is development. The developer creates a feature branch, works locally — in NZRT’s case that means using the Laragon environment — writes commits with descriptive messages, and pushes the branch up to GitHub when ready.

Stage three is code review. The developer opens a pull request from their feature branch and requests between one and two reviewers. Reviewers leave comments, the developer responds and makes any needed changes, pushes those updates, and then waits for approval.

Stage four is merge and deploy. Once the pull request is approved, the maintainer clicks merge. From there, GitHub Actions takes over and automatically deploys to staging. Tests run, and the team gets notified in Slack.

Stage five is the wrap-up. The pull request closes automatically. The feature branch gets deleted automatically. If the pull request was linked to an issue, that issue closes automatically too. And the project board gets updated to reflect that the work is done.

What’s worth noting about this workflow is how much of it is automated. Once the merge happens, you’re not manually chasing down steps — GitHub and the Actions pipeline handle the heavy lifting. That’s what keeps the team moving without communication gaps.

The main takeaway here is that GitHub’s collaboration tools aren’t just about storing code. They’re a full coordination layer for your team — from the moment an idea is captured as an issue, all the way through to it being deployed and confirmed done on the project board.

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

000LLM

Llm Wiki Schema

Welcome to the NZRT Wiki Podcast. Today we’re looking at LLM Wiki Schema.

This episode covers how notes are structured in the NZRT LLM knowledge vault. Whether you’re creating a new skill file or reviewing an existing one, this schema tells you exactly what to include and how to format it.

Let’s start with the frontmatter — that’s the block of metadata sitting at the very top of every skill note, before any main content. Think of it as the ID card for your document.

The frontmatter is written in a format called YAML, and it contains eight fields. Here’s what each one does.

First, tags. Required, and it holds a list of labels that make your note searchable and categorisable. Every note gets the vault-level tag 000LLM, the general LLM tag, a category tag, and a skill-specific slug. We’ll come back to those in a moment.

Second, aliases. Also required. These are human-readable names for the skill — alternative ways someone might refer to it, so if your file uses a technical slug, aliases give you the friendly labels people would actually search for.

Third, role. Required, and always set to the vault maintainer role, which in this case is xc.

Fourth, category. Required. This tells you which broad type the skill belongs to. There are seven options, and we’ll cover those shortly.

Fifth, complexity. Required. Low, medium, or high — reflecting how much effort the skill takes to implement.

Sixth, status. Required. A note moves through three stages: draft, review, and complete. This field tracks where it sits in that lifecycle.

Seventh, created. Required. The date the note was first made, in ISO 8601 format — that’s year, then month, then day.

Eighth, related. Optional. This lets you link out to other skill notes connected to this one.

Now let’s talk about the body of a skill file. Every note follows the same section order, and that consistency is what makes the vault navigable.

You start with the skill name as the top-level heading, followed by a single sentence defining what the skill is. Then comes an overview explaining what the skill is, what an LLM does when performing it, and why it matters. After that, a section called How It Works gives you a step-by-step or conceptual breakdown of the mechanism.

Next is Prompt Patterns — this is where reusable templates live. Placeholders in those templates are written in a specific style: all uppercase letters, words separated by underscores, and wrapped in double curly braces. So something like “document text” would appear as a placeholder in that format rather than as plain words.

Then you have an Examples section with concrete input and output pairs showing the skill in action, followed by NZRT Applications, which maps the skill to real work across WordPress, Dolibarr, Nextcloud, or TOGAF. After that comes Parameters and Tuning, covering things like temperature settings, token limits, and model recommendations. Then Limitations, documenting known failure modes and when not to use the skill. And finally, Related Skills, with links to connected notes and a one-line explanation of each relationship.

Now let’s cover the seven category types. Foundational covers core LLM techniques that everything else builds on — prompt engineering sits here. Text-processing is for skills that take input and transform it into a different form of text, such as summarization, extraction, and classification. Development covers code and technical artifact generation. Retrieval is about grounding LLM output in source documents — this is where RAG and question answering live. Analytical covers multi-step reasoning over complex inputs. Integration connects LLMs to external systems, like tool use and function calling. And architecture handles multi-LLM orchestration and agent design — things like pipelines and agent frameworks.

The tag taxonomy builds on all of this. At the top level you have three general tags: one for the vault itself, one for general LLM content, and one for broader AI and machine learning context. Then come the seven category tags matching the types we just covered. Each individual skill note also gets its own slug tag — examples include prompt-engineering, code-generation, summarization, data-extraction, question-answering, classification, reasoning, tool-use, rag, and agents. Finally, there are integration tags for the specific systems this vault connects to: wordpress, dolibarr, nextcloud, togaf, and nzrt.

The naming conventions are straightforward. Skill files live in a Skills folder and use lowercase words separated by hyphens, with a dot-md extension. Section headings use title case. And wikilinks use the slug form of the skill name.

Finally, the complexity guide gives you a clear way to decide which level applies. Low means a single prompt with no external dependencies that works reliably out of the box. Medium means you’ll need some prompt tuning, a few examples to guide the model, or some light post-processing of the output. High means you’re dealing with system design, external tools, retrieval pipelines, or multi-step chains.

That covers the full schema — frontmatter, body structure, categories, tags, naming conventions, and complexity levels. If you’re writing a new skill file for the vault, this is your complete checklist.

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

000NCL, 06 - Administration

Apps Plugins

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📦 Apps & Plugins.

Nextcloud on its own is already a powerful platform, but where it really shines is in its app ecosystem. You can extend what Nextcloud does by installing apps and plugins that plug straight into the core system. At NZRT, there’s a curated list of recommended apps that are either already installed or considered essential additions, and today we’re going to walk through all of that.

So let’s start with the recommended apps. There are three broad categories to think about: core functionality, security, and compliance or performance.

On the core side, you’ve got Talk, which handles chat, video, and calls. Then Calendar for scheduling and events, and Contacts for your address book. Deck handles task management, and Collectives gives you a built-in wiki and documentation space. Rounding out the core apps is Nextcloud Office, which lets you edit documents directly inside Nextcloud.

Then there are the security-focused apps. User LDAP handles Active Directory integration, so your existing user accounts can connect through. Two-Factor Authentication lets you enforce two-factor login across the platform. And Suspicious Login does exactly what it sounds like — it watches for unusual access patterns and flags anomalies.

Finally, from a compliance and performance angle, Audit Logging captures compliance-grade logs of activity on the system, and Full-Text Search indexes your documents so you can actually find things quickly.

Now, when you need to install a new app, you’ve got two ways to do it. The first is through the graphical interface. You go into Settings, then across to Apps, and you use the search field to find the app you want. Once you find it, you hit Install, approve whatever permissions it asks for, and then enable it. That’s the straightforward GUI route — no command line needed.

The second method is through the command line, and this is what system administrators often prefer for consistency and automation. There are two commands you’d run in sequence. The first tells the system to install the app by name. The second command then enables it so it becomes active. Simple two-step process on the server side.

Speaking of permissions — and this is important — whenever you’re installing an app, you should always stop and review what access it’s asking for. There are three main things to look at. First, file access: can this app read or write to user files? Second, user data: can it see usernames and email addresses? And third, admin functions: can it actually change system settings? These aren’t just checkbox exercises. Understanding what an app can access is how you prevent unintended data exposure.

Which brings us to how NZRT actually handles this process. It’s not a free-for-all. There’s a structured approval workflow before any new app hits production. Step one, your admin — that’s xc — evaluates whether the app actually meets the business requirement. Step two, there’s a permissions and security audit to understand what the app touches and whether that’s acceptable. Step three, the app gets tested in a staging environment first, not straight onto the live system. Step four, once it passes testing, it gets deployed to production and users are notified. And step five, the team monitors it after deployment — if something doesn’t look right, the app gets disabled.

The key people involved in that vetting process are xc on the admin side and dan on the security side. Together they make sure nothing goes into production that could cause data leakage or introduce vulnerabilities.

The bigger picture here is that apps are how you make Nextcloud fit NZRT’s actual workflows rather than working around a generic tool. Talk keeps internal communication inside the platform. Deck and Collectives mean project management and documentation don’t have to live in separate external systems. Office means you’re not exporting files to edit them elsewhere. Each app closes a gap, and the approval process makes sure closing that gap doesn’t open a new one.

If you want to dig deeper into related topics, the wiki also covers Administration Overview, Performance Tuning, and Audit Logs — all connected to this area.

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

000NCL, 02 - Collaboration Apps

Calendar

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Calendar.

If you’ve ever missed a deadline because someone forgot to tell you about a meeting, or you’ve had to chase a teammate just to find out when a client call is happening, then shared calendaring is exactly what this episode is about. Nextcloud Calendar is the solution NZRT uses to keep the whole team on the same page when it comes to scheduling, events, and time.

So what can Nextcloud Calendar actually do? Let’s walk through the core features. First up, you get shared calendars, which means you can have team-wide, project-specific, or role-based calendars that multiple people can view and contribute to. Next, there are event invitations with RSVP and attendance tracking, so when you send someone a calendar invite, you can actually see whether they’ve accepted, declined, or are still sitting on the fence. You also get recurring events, which are great for things like daily standups, weekly team meetings, or monthly finance reviews where you just set it once and it keeps showing up. Then there’s CalDAV sync, which we’ll talk more about in a moment, colour coding so you can visually tell your calendars apart at a glance, and full time zone support for when you’re working across different regions.

Now let’s look at how NZRT has structured its calendars. There are four main calendars set up. The first is the Team Calendar, owned by xc, with all team members having access. That one is used for company-wide events like public holidays and company announcements. The second is the Sales Calendar, owned by cas, used by the sales team to track client calls and demos. The third is the Finance Calendar, owned by fin, shared with fin and sun, and used for things like payment deadlines and month-end close activities. And the fourth is the HR Calendar, owned by han, shared with han and xc, covering onboarding schedules, performance reviews, and time-off requests. So depending on your role, you’ll likely be a member of one or more of these calendars, each colour coded and kept separate so the right information reaches the right people.

Now, one of the really useful things about Nextcloud Calendar is that it doesn’t just live inside the Nextcloud web interface. You can sync it directly to your phone or your desktop calendar app. There’s a section in the wiki that shows you how to do this, so let me walk you through what it describes. You start by opening your calendar app on iOS or Android, then you add a new account and choose CalDAV or CardDAV as the account type. From there, you enter the server address, which for NZRT is the internal Nextcloud address, then you put in your username and password using your LDAP credentials, the same ones you use to log in to Nextcloud. Once that’s done, your calendar app will automatically sync your events down to your device. So any event added to Nextcloud Calendar by a teammate will show up on your phone, and anything you create on your phone will push back up to Nextcloud. It keeps everything in one place without you having to manually check the web app every morning.

If you’re an Outlook user or you use Apple Calendar on a Mac, the same CalDAV protocol works there too. The process is similar, you point the app at the Nextcloud server using your credentials, and you get two-way sync from that point on.

From a broader NZRT perspective, the calendar isn’t just a standalone scheduling tool. It connects to how the whole organisation operates day to day. If you’re working on a Dolibarr project, you can align your calendar events with project milestones and deadlines. If you’re involved in the WordPress editorial side of things, calendar visibility helps coordinate content publishing schedules. And for the team doing Nextcloud maintenance, having a shared calendar means maintenance windows are visible to everyone before they happen, not after.

For fin and sun in particular, who manage payment schedules and vendor deadlines, the Finance Calendar is a practical tool for making sure nothing slips through the cracks at end of month when things tend to get hectic.

So whether you’re in sales tracking your client calls, in HR managing onboarding timelines, or in finance keeping an eye on payment due dates, Nextcloud Calendar gives your team a single, shared view of what’s happening and when. And with CalDAV sync, that view travels with you on whatever device you prefer to work on.

If you want to dig deeper, the wiki also links out to related notes covering the broader Nextcloud collaboration overview, Contacts, and the combined Email and CalDAV CardDAV integration guide, which is worth a read if you want to get everything connected at once.

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

000NCL, 02 - Collaboration Apps

Collaboration Overview

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

If you’ve ever juggled Slack for chat, Zoom for video calls, Google Calendar for scheduling, Asana for task tracking, and a separate wiki for documentation — all while wondering why your team’s data is scattered across half a dozen external platforms — this episode is for you. At NZRT, the answer to that problem is Nextcloud’s built-in collaboration suite, and today we’re going to walk through what it includes, who uses it, and why it matters.

So let’s start with what the collaboration suite actually is. Nextcloud isn’t just a file storage platform. It ships with a set of apps — Talk, Calendar, Contacts, Deck, and Collectives — that together cover almost everything a team needs to communicate and coordinate. And because it’s all self-hosted within NZRT’s own infrastructure, your data stays inside the organisation. No third-party SaaS subscriptions, no data leaving the building, so to speak.

Let’s go through each of those apps one by one.

First up is Talk. This is your chat and video calling tool — and if you’re familiar with Slack or Zoom, Talk covers that same ground. You can send messages, hop on video calls, and share your screen, all from within Nextcloud. At NZRT, Talk is available to everyone across all roles, so it’s the go-to channel for real-time team communication.

Next is Calendar. This is a shared calendar and scheduling tool, similar to Google Calendar. At NZRT, it’s used primarily by xc, sun, and fin — so that covers the executive, the operations side, and the finance function. It keeps scheduling in one place without needing to hand your calendar data over to an external provider.

Third is Contacts. This is the team’s shared address book, and it also connects to CRM-style data. At NZRT, it’s used by xc, pam, and cas — the executive, the project and marketing agent, and the customer and sales agent. If you need to look up a contact or manage relationship data, Contacts is where you go.

Fourth is Deck. Think of this as NZRT’s Kanban board and task management tool — essentially the replacement for Asana. You can create boards, move tasks through stages, and keep project work organised visually. At NZRT, Deck is used mainly by pam and dan — the project agent and the data and analytics agent.

And fifth is Collectives. This is the team wiki and documentation tool. If you need to write up processes, maintain internal docs, or collaborate on written content, Collectives is the place for that. At NZRT, that’s xc, ema, and dai — the executive, the email and comms agent, and the data insights agent.

Now, beyond the individual apps, there are some integration benefits worth understanding, because this is where the suite really earns its place.

The first is single sign-on. Your directory credentials work across all of these apps, so you’re not managing separate logins for each tool. One set of credentials, everything connected.

The second benefit is file integration. Because these collaboration apps live inside Nextcloud, you can share files directly from a chat conversation or attach them to a task on your Deck board. There’s no copy-paste shuffle between a file storage app and your communication tool — it’s all in the same place.

Third is a unified notification hub. Rather than checking five different apps for alerts, Nextcloud consolidates notifications across Talk, Calendar, Deck, and the rest. You get a single stream of what needs your attention.

And fourth is API access. The Nextcloud collaboration apps support automation and third-party integrations, which means agents and scripts can interact with these tools programmatically. That’s important for NZRT’s agent-driven workflow, where automated processes need to read and write data across systems.

Stepping back, the bigger picture here is that all of this — chat, video, calendar, contacts, task boards, and documentation — stays within NZRT’s secure, self-hosted infrastructure. You’re not depending on Slack staying affordable, Zoom’s terms of service, or Google’s data practices. The organisation controls the environment, the data, and the access.

So whether you’re coordinating a project on Deck, catching up on messages in Talk, or pulling up a shared process document in Collectives, it’s all running on the same platform, under the same credentials, with the same security boundary.

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

000NCL, 02 - Collaboration Apps

Collectives Wiki

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📖 Collectives (Wiki).

If you’ve ever needed a central place where your team can write, edit, and find documentation together, Nextcloud Collectives is exactly that. It’s a wiki platform built into Nextcloud, designed for collaborative team documentation. Think onboarding guides, standard operating procedures, runbooks — anything your team needs to know, all in one searchable, version-controlled place.

So what can you actually do with it? Let’s walk through the key features.

First, you get wiki pages. You can write using either a Markdown editor if you’re comfortable with plain text formatting, or a more visual WYSIWYG editor if you prefer something closer to a word processor. Your choice, depending on how you like to work.

Second, pages can be nested. That means you can organise your documentation into hierarchies — a parent page with child pages underneath it, and so on. If you’re familiar with how this Obsidian vault is structured, it works in a very similar way.

Third, Collectives supports real-time collaboration. Multiple people can co-edit a page at the same time, and there’s also a comments system so you can leave feedback or questions right on the document itself.

Fourth, every time someone edits a page, Collectives automatically saves a snapshot. That version history means you can always look back at what changed, when it changed, and roll things back if something goes wrong.

Fifth, you have flexible permission control. You can make a collective public, restrict it to a specific team, or keep it private. That gives you good control over who sees what, which matters when you’re mixing internal-only processes with content you might want to share more broadly.

And sixth, there’s full-text search across all your wiki content. So instead of hunting through folders, you can just search for a keyword and find the relevant page quickly.

Now, to give you a practical sense of what a page might look like, imagine a simple onboarding checklist. The page would have a main heading like Onboarding Checklist, then two sections underneath it. The first section covers IT Setup, and it lists three tasks — creating an LDAP account, which is handled by xc, adding the new person to Nextcloud groups, and issuing a laptop with VPN access. The second section covers Access, and it lists three more tasks — setting up a Dolibarr login handled by fin, granting access to the relevant Nextcloud shared folders, and sending Talk channel invitations. That kind of structured, actionable checklist is exactly the type of content Collectives is built for.

If you want to explore related areas, you might also look at the Collaboration Overview, the Document Management Overview, and the NZRT Folder Structure notes, which all connect to how Collectives fits into the broader way NZRT organises its information.

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

000NCL, 02 - Collaboration Apps

Deck Kanban

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Deck (Kanban).

If you’ve ever used a physical sticky-note board to track work — with columns for To Do, In Progress, and Done — you already understand the concept behind Nextcloud Deck. Deck is NZRT’s built-in Kanban tool, living right inside Nextcloud, and it’s how our teams organise and track tasks and projects without needing any external software.

Let’s start with how Deck is structured. At the top level, you have boards. A board is your project workspace — think of it as the whole whiteboard. Inside each board, you have columns, which represent the stages of your workflow. Out of the box you might have To Do, In Progress, and Done, but you can customise these to match however your team actually works.

Inside those columns, you have cards. A card represents a single task or work item, and each card can hold quite a bit of information. You can write a description, set a due date, assign it to a specific person, attach labels for easy filtering, and link files directly to the card. So if a task needs a document or spreadsheet, it travels with the card. Cards also have a comments section, which means your whole team can collaborate and leave notes directly on the task — keeping everything in one place rather than scattered across emails.

Beyond the cards themselves, Deck also tracks activity. You can see a history of who moved a card, when they moved it, and what changed. That audit trail is really useful when you need to understand the progress of a project or figure out where something got held up. Boards can also be shared with individual team members, with groups, or made publicly accessible — so you have real flexibility in how you open your workflow up to the people who need it.

Now let’s talk about how NZRT specifically uses Deck. There are five active boards across the team. First, the Marketing Pipeline — owned by pam and used by the Products team for campaign planning. Second, Sales Deals — owned by cas, used by the Sales team to track deal progression. Third, Procurement — owned by sun, where the Procurement team tracks purchase orders. Fourth, Tech Projects — owned by dan on the DBA team, covering system upgrades and Nextcloud maintenance. And fifth, the Editorial Calendar — owned by ema on the EDM team, used to plan and schedule WordPress and blog publishing.

To give you a concrete sense of what a card actually looks like, imagine one titled “Prepare Q2 Sales Report”. It has a description explaining the work — aggregating CRM data and creating visualisations. It is assigned to cas in the Sales role. It has a due date set, labels applied for sales, reporting, and urgency, and a file attached — a sales report template pulled from the Finance folder in Nextcloud. Then there is a comments area where team members can check in and collaborate as the task moves forward.

One of the biggest wins for NZRT with Deck is that it removes the need for external project management platforms. Tools like Asana or Monday dot com are no longer needed, because Deck provides the same core functionality right inside Nextcloud, where your files already live. For the Products team, the Sales team, and the DBA team in particular, Deck has become the go-to for daily task tracking — and it has replaced a lot of the email-based back-and-forth that used to slow things down.

If you want to dig deeper, check out the related wiki pages on the Collaboration Overview, the Files App, and NZRT User Roles and Agents. Those will give you more context on how Deck fits into the broader Nextcloud environment and how the different team members interact with it day to day.

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

000NCL, 03 - Document Management

Document Management Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Document Management Overview.

If you work with documents at NZRT — and chances are you do — this episode covers how everything fits together. We’re talking about how Nextcloud’s document management tools and Dolibarr ERP work in tandem to keep contracts, invoices, and business records organized, versioned, and compliant.

Let’s start with the tools you have available inside Nextcloud. There are five key features in the document management suite. First up is Nextcloud Office, which runs OnlyOffice as an editor built right into the platform. That means you can create and edit documents — word processing files, spreadsheets, presentations — without ever leaving Nextcloud or touching an external cloud service. Everything stays in-house.

Next is the PDF Viewer. This one is more powerful than it sounds. You can annotate PDFs, highlight sections, add comments, and even sign documents. You can also preview a file before you download it, which saves you time when you’re hunting through a busy folder.

Then there’s Tagging. You can organize your documents with searchable tags — things like invoice, contract, or draft. This makes it much easier to find what you’re looking for without needing to remember exactly where you saved something.

Alongside tagging, you’ve got full-text Search. That means Nextcloud can look inside your documents — not just at filenames — and return results based on the actual content. Very useful when you know what a document says but not what it’s called.

And finally there’s Retention. This is an automated feature that removes old documents according to your defined policy. If something has a set lifespan, Nextcloud handles the cleanup for you without any manual work on your end.

Now let’s talk about how documents actually flow through NZRT. There’s a three-stage workflow. It begins in Dolibarr, where documents are created — things like invoices, contracts, and purchase orders originate in the ERP system. From there, they move into Nextcloud for storage and version control. Inside Nextcloud, the Files app handles the actual file storage, Nextcloud Talk supports approval conversations, and Nextcloud Deck helps with tracking where a document is in its lifecycle. The third stage is archiving. Documents that are ninety days old or older get moved out to external storage, and that includes a NAS backup for long-term retention.

Now let’s look at who owns what. There are five document types at NZRT, and each one has a designated owner, an approver, and a defined archive period. Invoices are owned by the finance agent and approved by xc, the executive controller, and they’re kept for seven years to satisfy legal requirements. Contracts are handled by the client and accounts services agent, also approved by xc, and retained indefinitely. Purchase orders belong to the supply and resources agent, are approved by the finance agent, and kept for three years. HR records are managed by the HR and admin agent, approved by xc, stored for seven years, and importantly they’re encrypted. And finally, reports are produced by the data and intelligence agent, approved by xc, and held for five years.

So why does all of this matter in the NZRT context? Document management sits right at the heart of the Dolibarr ERP workflow. Every invoice, contract, and purchase order that moves through the business ends up in Nextcloud for storage, versioning, and approval tracking. That’s not just about staying organized — it’s about staying compliant with both business requirements and legal obligations. Having a clear chain of ownership and defined retention periods means you always know where a document is, who approved it, and how long it needs to be kept.

If you want to go deeper on any of these topics, there are related notes in the wiki covering Nextcloud Office, the PDF Viewer, Tagging and Search, and the Dolibarr integration specifically. Each of those gives you more detail on the individual components covered today.

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

000NCL

Email Caldavcarddav

Welcome to the NZRT Wiki Podcast. Today we’re looking at Email & CalDAV/CardDAV.

If you’ve ever wondered how your Nextcloud calendar and contacts end up on your phone or in your email client without going through Google or Microsoft’s cloud, this episode is for you. The answer is two open protocols called CalDAV and CardDAV, and Nextcloud supports both out of the box.

Let’s start with CalDAV. The protocol is defined under RFC 4791 and it’s the standard that lets calendar apps talk to a server over the web. On the NZRT setup, the endpoint for calendar sync sits at the Nextcloud server address, followed by a path that includes the word “dav”, then “calendars”, then “users”, and then the specific username. So every user gets their own calendar path on that server.

Setting it up on iOS, Android, or Outlook follows the same basic flow regardless of the app. You go into your device or app’s settings, find the calendar section, choose to add an account, and select CalDAV as the account type. You enter the server address, which is the Nextcloud server hostname, your LDAP username, and your LDAP password. Once you save that, the client auto-discovers all the calendars tied to your account. That’s it. No third-party service involved.

Now for contacts, the protocol is CardDAV, defined under RFC 6352. The server path is almost identical to the calendar one, except instead of “calendars” in the URL you’ll see “addressbooks”. The credentials are exactly the same as CalDAV, so you’re using your LDAP username and password again. On Apple Contacts or Android, you go into the contacts settings, add an account, choose CardDAV, enter those same details, and from that point on all your Nextcloud Contacts groups sync down to the device.

For desktop email clients like Outlook or Thunderbird, the calendar subscription works slightly differently. Instead of adding an account, you typically go into the calendar area, find an option to subscribe to a calendar, and paste in the full URL for the specific calendar you want. That URL includes the server address, the same dav path, and then the calendar name at the end. You authenticate with your LDAP credentials and the calendar appears alongside your other calendars in the client.

Now let’s talk about how the sync actually behaves once everything is connected. It runs two ways, meaning changes you make in Nextcloud show up on your phone, and changes you make on your phone sync back to Nextcloud. By default the sync happens roughly every fifteen minutes, though that interval is configurable if you need it more or less frequent. If two devices edit the same event or contact at the same time, the system uses a last-write-wins approach, so whichever change was saved most recently is the one that sticks.

From an NZRT perspective, this setup is particularly useful for keeping the sales team, the finance team, and HR in sync across desktop and mobile. Because everything goes through the internal Nextcloud server, you’re not routing calendar data through external services like Google Calendar or Outlook cloud. Your scheduling data stays within the NZRT environment.

If you want to dig deeper into any of the pieces that make this work, the related topics to look up in the wiki are Calendar, Contacts, and the REST API and WebDAV page.

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

000NCL, 08 - Reference

Nextcloud Apps Directory

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📱 Nextcloud Apps Directory.

So if you’ve been wondering what apps NZRT recommends layering on top of Nextcloud, this episode walks you through the full catalog — what each app does, who at NZRT uses it, and whether it’s considered essential or just optional.

Let’s start with the core communication apps. These are the ones that keep the team connected day to day. First up is Talk, which handles chat, video calls, and screen sharing — version 17 or higher, and it’s used by everyone across the org. Then you’ve got Calendar for shared scheduling, mainly used by xc, sun, and fin. Contacts gives you an address book and light CRM functionality, and that’s in the hands of xc, pam, and cas. Mail is also available for email integration, though it’s flagged as optional and mainly relevant to fin and han.

Moving into productivity and project management apps. Deck is a Kanban-style board for task management — think cards and columns — and pam, cas, sun, and dan all rely on it. Collectives is a wiki-style documentation tool, used by xc and ema for team knowledge bases. Nextcloud Office integrates OnlyOffice so you can edit documents right inside Nextcloud — that’s a core app for ema, fin, and pam. Tasks and Notes round out this category as optional tools available to everyone if they want lightweight to-do lists or quick note capture.

For file management, most of the heavy lifting comes from built-in apps. You’ve got the core Files app, Groupfolders for setting up team folders with proper permissions, External Storage for mounting things like NAS drives or S3 buckets, and then the usual suspects — Trash for the recycle bin, Versions for file history, and Sharing for passing files and folders around. All of these are available to everyone, with a few like Groupfolders and External Storage being managed by xc or dan.

Now security and admin — this section matters a lot. User LDAP connects Nextcloud to directory services for authentication. Two-Factor Auth enforces 2FA at the platform level. Suspicious Login watches for anomalous login patterns. Audit Logging keeps compliance records. And Brute-Force Protection throttles repeated failed login attempts. All of these are core and sit firmly in xc’s domain, with dan also involved in LDAP and audit logging. On top of those, you’ve got optional extras: OTP for one-time passwords, and FIDO2 WebAuthn if you want hardware key support.

Integration and automation apps are next. Webhooks let you trigger automation based on events inside Nextcloud — that’s useful for dan and ema. The REST API and WebDAV support are built in and used by everyone for file sync and system integrations. OAuth2 is available optionally for third-party authentication flows, managed by dan.

For search and performance, Full-Text Search with Elasticsearch integration lets you search inside documents, not just filenames — that’s recommended and looked after by dai and ema, with dan handling the Elasticsearch side. Redis is the caching backend and is core infrastructure managed by dan.

In the Office and Document category, Nextcloud Office appears again because it’s that central — ema and fin use it for document collaboration. PDF Viewer supports annotation and viewing, used by fin, cas, and han. Text is a plain text editor available to all as optional. Markdown Editor is also optional and mainly used by ema and dai.

For CRM and ERP integration, the REST API built into Nextcloud is what connects to Dolibarr and WordPress. Webhooks can be layered on top for event-driven sync. Both are managed by ema and dan.

Backup and disaster recovery wraps things up. There’s a Backup app for built-in backups managed by dan, and External Storage doubles as a backup mounting point for NAS.

There’s also a short list of apps NZRT does not recommend. Nextcloud Hub is noted as already built in, so no separate install needed. Pricing Plans is a SaaS-only concept that doesn’t apply here. Custom Apps require vetting before use. And Third-Party Cloud Storage is skipped in favour of the External Storage app instead.

Now, the wiki includes an installation script — and rather than reading you lines of code, here’s what it does in plain terms. It defines a list of recommended app names — things like talk, calendar, contacts, deck, collectives, the Nextcloud Office package, user LDAP, two-factor auth, suspicious login, full-text search, audit logging, and groupfolders. It then loops through that list one by one, installs each app, enables it, and prints a confirmation message so you can see what’s been set up. It’s a clean, repeatable way to get a fresh Nextcloud instance up to NZRT standard in one go.

To zoom out: the whole point of this app catalog is to make Nextcloud actually work for NZRT’s specific setup. That means tight Dolibarr integration via the REST API, team communication through Talk and Calendar, and solid document workflows through Office and PDF Viewer. Every app on the core list has a clear owner and a clear job.

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

000NCL, 01 - Files & Storage

Files App

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Nextcloud Files App.

If you’ve ever wondered where all the team’s documents live and how they stay organised, this is the episode for you. The Nextcloud Files App is the core file management interface — your central hub for uploading, organising, sharing, and collaborating on files across the business.

Let’s start with what it can do. First, you’ve got a web interface and a desktop client, so you can upload, download, and sync files across your devices whether you’re at your desk or on the go. There’s also sharing built right in — you can create public links or share directly with specific users or groups, and you can attach expiry dates and password protection to those links for added control. The app supports tagging too, which lets you label your files with keywords that are searchable across the entire vault, making it much easier to find things when you need them. Versioning is another powerful feature — Nextcloud automatically keeps a history of your files, so if something gets changed or overwritten by mistake, you can go back and restore a previous version. For sensitive material, end-to-end encryption is available, meaning only the intended recipients can read the content. And finally, there’s an activity feed that tracks who changed what and when, giving you full visibility over everything happening in your file space.

Now let’s talk about how files are actually organised. The recommended folder structure has three top-level areas. The first is a Shared folder, which is designed for team collaboration. Inside it you’ll find subfolders for Finance, HR, Sales, and Projects — think of this as the communal workspace where multiple people need access. The second top-level area is a Documents folder, which is your personal storage space. It contains subfolders like Invoices and Reports, things that belong to you individually. The third area is an External folder, which connects to storage outside of Nextcloud itself, such as a NAS backup device. So to summarise: Shared for the team, Documents for yourself, and External for anything coming in from outside the platform.

Now for the NZRT-specific context, and this is important if you’re part of the team. The Files App doesn’t operate in isolation. It integrates directly with Dolibarr, NZRT’s ERP system, which means invoices, contracts, and purchase orders can be stored here and referenced from there. It also connects with WordPress, so media assets and blog drafts can flow through Nextcloud straight into the website. The person responsible for managing folder structure and permissions across all of this is the EDM role, which in NZRT’s agent framework corresponds to the ema agent.

If you want to dig deeper, the wiki links out to related articles on External Storage, File Sharing and Links, Versioning and Trash, and Encryption — each with its own dedicated page.

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

000NCL, 01 - Files & Storage

File Sharing Links

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud File Sharing and Links.

If you’ve ever needed to get a document to a client quickly, or make sure only the right people inside your organisation can see a sensitive file, then this is the episode for you. Nextcloud gives you a surprisingly fine level of control over who sees what, how long they can see it, and what they can actually do with it once they have access.

Let’s start with the four main ways you can share something in Nextcloud.

The first is a user or group share. This is your standard internal share where you’re giving a specific person or a team direct access. Think of it as internal team collaboration — the people you share with log in and see the file in their own Nextcloud account.

The second type is a public link. This is what you’d use for external sharing, like sending something to a client or making a file available for download without the recipient needing a Nextcloud account. Public links can be protected with a password and given an expiry date so they don’t stay active forever.

The third type is called a federated share. This one’s a bit more advanced — it lets you share files across completely separate Nextcloud instances. So if a partner organisation runs their own Nextcloud server, you can share directly with them without emailing attachments back and forth.

And the fourth type is resharing. This is where someone you’ve shared a file with can then share it on to someone else — a kind of delegation of access. This can be useful but it’s worth being aware of when you allow it, since it means your original share can spread further than you intended.

Now, when you create a public link, there are several settings you can configure. Imagine you click the share button in Nextcloud and choose to create a link. What you’re looking at is a panel that lets you set an expiry date — by default, seven days from creation. You can also set a password so that only someone with that password can open the link. You control the permissions, which by default are set to view only, meaning the recipient can look at the file but not edit it. And you can choose to notify someone by email so they get the link sent directly to them. A key best practice here: if you’re sharing a sensitive document, consider disabling the download option entirely and keeping it in view-only mode. That way the recipient can read it but can’t save a local copy.

Now let’s talk about how different teams at NZRT actually use these sharing features in practice.

For the sales side of things, the agent known as cas uses public links when sharing contracts with clients. Those links are set with a thirty-day expiry, which gives clients enough time to review without leaving links active indefinitely.

Finance, handled by fin, takes a much more restricted approach. Invoices and financial documents are shared only via direct user shares — no public links at all. That keeps sensitive financial data inside the system and away from the open web.

Human resources, managed by han, goes one step further for things like payroll data. Those shares use end-to-end encryption, which means the content is encrypted on your device before it even reaches the server. Only the intended recipient can decrypt and read it.

And then there’s ema, who manages document retention. Rather than letting old shared files pile up forever, ema applies retention policies that automatically delete documents after ninety days. This is a really useful practice for keeping the file system clean and making sure old shared links don’t become a security risk down the line.

Stepping back and looking at the bigger picture for NZRT as a whole: the goal of all this is to make sure the right things are accessible to the right people, for exactly as long as they need to be. Dolibarr invoices and HR records stay locked down through user-only or encrypted shares. At the same time, external parties like clients and vendors can still get what they need through time-limited public links that expire automatically.

If you want to go deeper on any of this, there are three related topics worth exploring in the wiki. The Files App covers how to navigate and manage your files day to day. The Encryption page goes into detail on how end-to-end encryption works and when to use it. And the Permissions and Sharing page gives you the full breakdown of what each permission level actually allows a recipient to do.

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

000NCL, 03 - Document Management

Nextcloud Office

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Office.

If you’ve ever wished you could edit a Word document, a spreadsheet, or a presentation without leaving Nextcloud — that’s exactly what Nextcloud Office gives you. It integrates OnlyOffice directly into the Nextcloud interface, so everything stays on NZRT’s own infrastructure. No Microsoft Office subscription, no Google Docs, no third-party SaaS tools — just your files, in your cloud, with a full-featured office editor built right in.

Let’s start with what file types you can work with. On the document side, you’ve got the standard Word formats — docx, odt, and doc — so whether you’re coming from Microsoft Word or LibreOffice, you’re covered. For spreadsheets, you can open and edit xlsx, xls, and ods files. And if you need to work on a presentation, pptx, odp, and ppt are all supported. That covers the formats most teams will ever need.

Now let’s talk about what you can actually do inside those files. Nextcloud Office supports real-time collaboration, which means multiple people can be editing the same document at exactly the same time. You can see where everyone else’s cursor is sitting, live, as they type. That’s the co-editing feature, and it’s particularly useful when your team is spread across locations.

There’s also a comments and change tracking system built in. You can leave comments, make suggestions, and have other people review and accept or reject those changes — the same workflow you’d expect from a mature office suite. And if something goes wrong, or you just want to see what a document looked like before the last round of edits, version history has you covered. Nextcloud takes automatic snapshots before each edit session, so you’ve always got a trail to roll back to.

One more thing worth mentioning — mobile support. If you’re on a tablet and need to review or edit a document on the go, the Nextcloud mobile app gives you access to Nextcloud Office as well. So you’re not tied to a desk.

Now, NZRT has a set of standard document templates stored in the Shared Templates folder. There are four of them. First, a budget spreadsheet used by the finance team for budgeting work. Second, a Word document for legal contracts. Third, a presentation file used by the sales team for putting together proposals. And fourth, another Word document for standard operating procedures. If you’re creating any of those kinds of documents, start from the template rather than from scratch.

Let me touch briefly on how Nextcloud Office gets configured under the hood. There’s a command-line tool that Nextcloud uses for administration. To get Nextcloud Office running, you first enable an application called richdocuments — that’s the connector between Nextcloud and the OnlyOffice engine. Then you tell Nextcloud where the OnlyOffice document server is running. In NZRT’s setup, that server runs locally, and the configuration just points Nextcloud at its address. Once those two steps are done, the editor becomes available to everyone in Nextcloud automatically.

From an NZRT operations perspective, this matters because it removes the need for Microsoft Office licenses entirely. The finance agent, the sales agent, and the EDM agent all work directly in Nextcloud on budgets, proposals, and contracts. Version history means every change is tracked, giving you a clear audit trail of who edited what and when — and that matters a lot for any document with legal or financial weight.

If you want to dig deeper, there are related wiki pages on Document Management Overview, Tagging and Search, and Versioning and Trash — all of which connect to how Nextcloud Office fits into the broader document workflow at NZRT.

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

00 - Nextcloud Overview, 000NCL

Nextcloud Overview

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📚 Nextcloud Overview.

So, what is Nextcloud? At its core, Nextcloud is an open-source platform that handles file hosting, team collaboration, and communication — all in one place. Think of it as NZRT’s self-hosted alternative to something like Google Workspace or Microsoft 365. The key word there is self-hosted, which means NZRT owns and controls the infrastructure rather than relying on a third-party cloud provider. That matters for privacy, security, and integration flexibility.

For NZRT specifically, the Nextcloud instance runs on the Hoopla cPanel server — that’s the live, online server, not anything local. You can reach it at cloud dot nzrtnetwork dot com forward slash nextcloud. If you’re on the desktop, you’ll also find it synced locally to a folder called Nextcloud2 under the main user profile. So changes you make on the server show up on your machine and vice versa — that’s the sync client doing its job.

Now let’s walk through what Nextcloud actually does. There are six main capability areas worth knowing.

First, file sync and sharing. This is the bread and butter. You get cross-platform sync clients, so whether you’re on Windows, Mac, or mobile, your files follow you. You can create secure sharing links and set granular permissions, meaning you can control exactly who can view, edit, or download a file.

Second, collaboration tools. Nextcloud includes a built-in chat feature called Talk, which handles both text messaging and video calls. There are also shared calendars and something called Deck, which is a task board tool — similar to Trello if you’ve used that. So team coordination happens inside Nextcloud without jumping to external apps.

Third, the office suite. Nextcloud integrates with OnlyOffice, which lets you create and edit documents, spreadsheets, and presentations directly in the browser. No sending files to Google Docs or Microsoft 365 — it all stays within the NZRT ecosystem.

Fourth, document management and Dolibarr integration. This is a big one for NZRT. Nextcloud syncs with Dolibarr, which is the ERP system used for invoices, contracts, and project management. That connection means documents like invoices and contracts can be stored in Nextcloud with full version control, and Dolibarr can reference or manage them through its document module. It creates a proper approval and versioning workflow without manual file juggling.

Fifth, the API and WebDAV support. Nextcloud exposes a RESTful API and supports the WebDAV protocol. In plain terms, that means other systems and automation scripts can talk to Nextcloud programmatically — uploading files, reading folder contents, creating share links, all without a human clicking through the interface. This is how NZRT’s agents and scripts interact with Nextcloud behind the scenes.

Sixth, security. Nextcloud offers end-to-end encryption for sensitive files, supports single sign-on and LDAP directory integration, two-factor authentication, and keeps audit logs so you can track who accessed or changed what.

Now, zooming out to the NZRT picture — Nextcloud sits at the centre of NZRT’s self-hosted infrastructure and acts as the collaboration backbone. It’s the central file hub that the whole team works from, which means there’s no dependence on external cloud services for day-to-day document work. It bridges into Dolibarr for things like invoice storage, contract versioning, and document approval workflows. It also ties into WordPress, helping manage media assets and supporting author collaboration on content. And as mentioned, the Talk feature replaces external chat tools like Slack for internal team communication. Calendars and contacts round it out, feeding into scheduling and CRM use cases.

The service code for Nextcloud within NZRT’s systems is 000NCL — you’ll see that referenced in tickets, repos, and documentation whenever something relates to the Nextcloud platform.

If you want to go deeper, there are related wiki notes covering the architecture and tech stack, installation and setup, the admin dashboard, and NZRT-specific Nextcloud configuration. Those are worth exploring if you’re working on anything infrastructure-related or need to understand how the system was put together.

The short version: Nextcloud is NZRT’s self-hosted Google Workspace equivalent, running live on Hoopla, synced to your desktop, wired into Dolibarr and WordPress, and accessible via API for automation. It’s not just file storage — it’s the connective tissue for how the team works, shares, and communicates.

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

000NCL, 07 - NZRT Configuration

Nzrt Folder Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at NZRT Folder Structure.

If you’ve ever wondered how NZRT organises its files in Nextcloud, this episode walks you through the whole picture — from the top-level layout all the way down to individual folders for finance, HR, sales, and more. The structure is designed to match how the business actually works, and it ties directly into Dolibarr ERP, WordPress, and the various agent roles you might already be familiar with.

Let’s start at the top. There are four main areas sitting at the root level of Nextcloud. You’ve got Shared, which is the main team workspace. Then WordPress, which holds content for the website. Then Public, for sharing files with clients and vendors outside the organisation. And finally Archive and External, which handle long-term storage and connections to backup systems like a NAS drive or cloud archive on S3.

The Shared folder is where most of the action happens, and it’s owned by the EDM agent, ema. Inside Shared, you’ll find dedicated folders for Marketing, Sales, Procurement, Finance, HR, Analytics, Database, and a few others. Each one is scoped to a specific role — so for example, pam has read and write access to Marketing, cas handles Sales, sun looks after Procurement, fin owns Finance, han manages HR, and dai works across Analytics. There’s also a credentials folder that only xc, the admin, can access.

Let’s look at some of these in more detail.

The Finance folder sits under Shared and contains subfolders for invoices organised by month, purchase orders split into active and completed, bank statements which are end-to-end encrypted, budget files, and monthly reports. Access is limited to fin and xc. Bank statements require encryption — that’s non-negotiable. And everything in Finance is kept for seven years to meet legal requirements.

HR follows a similar pattern. You’ve got an Employees folder with subfolders for active and departed staff, and within each employee’s folder you’ll find things like their offer letter, contract, and performance reviews. There’s also a Payroll folder — also end-to-end encrypted — containing monthly payroll spreadsheets and reports. Then Onboarding, with checklists and forms, and a Policies folder holding documents like the code of conduct and benefits guide. Only han and xc can access HR, and like Finance, retention is seven years.

Sales is managed by cas and gives read access to pam as well. Inside you’ll find a Clients folder where each client gets their own subfolder containing contracts and quotes. There’s also a Proposals folder, a Deals area with a shared spreadsheet linked to the project board, and a CRM Export folder where Dolibarr contact exports land as CSV files. Public share links are enabled for contracts, but they expire after thirty days. Sales records are kept for three years.

Procurement, managed by sun, holds purchase orders organised by year, a Vendors folder where each vendor has their own space for contracts and pricing, a folder for requests for quotation, and a folder for invoices received from vendors. Finance also has read access here. Retention is three years.

There’s a Templates folder that all users can read but only ema can update. It contains finance templates like invoice and budget spreadsheets, sales templates including proposal slides and contract documents, HR templates for offer letters and NDAs, and general templates for things like standard operating procedures and meeting minutes.

The Analytics folder is owned by dai and is used for aggregating data across systems. You’ll find weekly and monthly report folders, and an Exports section with data pulled from Dolibarr and other systems. This folder rolls over on a one-year cycle.

The Database folder is managed by dan and stores daily and weekly backups, system logs, and a yearly archive. Daily backups are kept for thirty days, and weekly backups are retained for a full year.

One of the more technically interesting folders is Dolibarr EDM. This is where Nextcloud and Dolibarr connect directly. Documents generated in Dolibarr — invoices, contracts, purchase orders — are automatically synced into this folder every night at two in the morning via a webhook and REST API integration. You’ll also find a Sync Log folder that records what happened during each sync, including any errors. The folder is owned by ema.

To bring it all together — every folder in this structure maps to a real business role, has defined access permissions, specifies whether encryption is required, and sets a retention period. Nothing is left ambiguous. Whether you’re fin looking for an invoice from three months ago, or dan checking a database backup log, you know exactly where to go.

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

000NCL, 03 - Document Management

Pdf Viewer

Welcome to the NZRT Wiki Podcast. Today we’re looking at the Nextcloud PDF Viewer.

If you’ve ever found yourself downloading a PDF just to highlight a line or scribble a note, then uploading it again and emailing it to someone who needs to sign it — you know how tedious that loop can get. The Nextcloud PDF Viewer is built to cut that cycle out entirely. Everything happens right inside your browser, inside Nextcloud, without touching external software.

So let’s walk through what it can actually do for you.

First, the basics. When you open a PDF in Nextcloud, you get a fast, responsive viewer right in the browser. No waiting for Adobe to load, no plugin errors. From there, you’ve got a full set of navigation controls — you can zoom in and out, rotate pages, jump to bookmarks in longer documents, and select and copy text directly from the file. That last one is handy when you need to pull a quote from a contract without retyping it by hand.

Now, where it gets really useful is annotations. You can highlight text, underline it, strike through it, and attach notes — all without altering the original file in a destructive way. And you can digitally sign PDFs directly inside Nextcloud, embedding your signature right there in the document.

Let’s talk about how that annotation workflow actually looks in practice. You open your PDF in Nextcloud, then click the Annotate button. From there, you add your highlights, your notes, your signature — whatever the document needs. When you save, Nextcloud automatically creates a new version of the file, so the original is preserved and you’ve got a clean audit trail. Then you can share a link directly with whoever is next in your approval chain. No downloading, no re-uploading, no email attachments bouncing back and forth.

Now let’s talk about how NZRT teams actually use this day to day. There are four main areas where PDF Viewer makes a real difference.

Finance uses it to review invoices and contracts, and to add approval signatures without anyone needing to print a single page. Sales uses it to annotate proposals with client feedback — so when a client marks up a quote, those notes live right alongside the document in Nextcloud rather than in a separate email thread. HR uses it to sign offer letters and NDAs, again without printing. And on the document management side, annotated files can be archived with Dolibarr integration, so your signed and reviewed documents feed directly into your ERP records.

On the technical side, getting the PDF Viewer running on your Nextcloud instance is straightforward. There are two commands you’d run on your server. The first enables the PDF viewer app itself. The second enables a companion app for e-books, so your Nextcloud instance can handle that format as well. Both are single-line commands run through the Nextcloud command-line tool, and once they’re done, the functionality is live for your users.

To put it simply, for NZRT the big win here is eliminating the download-edit-reupload cycle entirely. The three roles that benefit most are Finance, Sales, and HR — referred to internally as fin, cas, and han. These are the people who are regularly handling contracts, proposals, and HR documents that need review and sign-off. By keeping all of that inside Nextcloud, you speed up approval workflows, reduce version confusion, and keep your document history tidy in one place.

If you want to dig deeper into related topics, the wiki also covers Document Management Overview, Nextcloud Office for live document editing, and Permissions and Sharing for controlling who can see and annotate your files.

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

000NCL

Podcast Folder Structure

Welcome to the NZRT Wiki Podcast. Today we’re looking at Podcast Folder Structure.

So, if you’ve ever wondered where all the NZRT Wiki Podcast audio files, transcripts, animated videos, and RSS feeds actually live, this episode answers that. Everything is stored in a structured folder inside Nextcloud, which is NZRT’s cloud file system hosted at cloud.nzrtnetwork.com. If you’re working locally, that same folder syncs down to your machine under your Nextcloud2 drive, inside Shared, then Content, then Podcasts.

Let’s talk about what that Podcasts folder actually looks like when you open it up. At the top level, the first thing you’ll notice is a file called feed.xml. That’s the master RSS feed — it covers every episode across every service. Sitting alongside it are a bunch of per-service feeds, each named with a service code. So you’ve got one for the x402 Knowledge Base API, one for Dolibarr, one for Blockchain, one for Flarum, one for GitHub, one for the LLM work, one for Nextcloud, one for Obsidian, one for WordPress, and so on. Each of those feeds covers only the episodes belonging to that particular service. There’s also a HOME.md file in there, which acts as an index document for the whole folder.

Below all those top-level files, you’ll find subfolders — one for each service code. So there’s a folder for 000API, one for 000DOL, one for 000BCH, one for 000NCL, and so on. Inside each subfolder you’ll find the actual episode files for that service. As an example, the 000API folder contains an mp3 file for the x402 overview episode, a txt file which is the full transcript for that same episode, and an mp4 file which is an animated visual companion for it.

That brings us to the three file types you’ll find for each episode. First, you have the mp3 file — that’s the actual audio, generated using a text-to-speech tool with an American English voice called Guy Neural. Second, there’s a txt file containing the full narration transcript — essentially the script you’re hearing right now, in text form. Third, some episodes also have an mp4 file, which is an animated visual version, created where that’s been set up for a particular episode.

Now, how do these audio files get shared publicly so podcast clients can actually play them? Each mp3 file gets a public, read-only share link created through Nextcloud’s sharing system. That link is set up as a public link with read-only access. The direct download URL from that share is then inserted into the RSS feed as what’s called an enclosure tag — that’s the standard way podcast apps know where to fetch the audio file from.

On the feed generation side, there’s a Python script called create_podcast.py that handles updating both the master feed and the relevant per-service feed each time a new episode is produced. Those feeds use the iTunes podcast namespace, which means they’re compatible with standard podcast apps. If you need to process a whole batch of wiki pages at once, there’s also a batch version of that script called create_podcast_batch.py, which will work through all the markdown files in a given wiki subfolder in one go. Both scripts live in the 000AGT repository on your local machine.

That’s really the full picture. A clean root folder with a master feed and per-service feeds, subfolders organised by service code, three file types per episode, public share links powering the RSS enclosures, and a pair of Python scripts keeping everything up to date.

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

000NCL, 01 - Files & Storage

Versioning Trash

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Versioning & Trash.

If you’ve ever accidentally overwritten a file — or needed to roll back a document to an earlier state — Nextcloud’s built-in versioning and trash features are what save the day. Let’s walk through how they work and how NZRT uses them.

First, the basics. Every time you change a file in Nextcloud, the system automatically takes a snapshot of it. You don’t have to do anything — it just happens in the background. So if you edit a contract, update a spreadsheet, or revise a report, Nextcloud quietly keeps a copy of what that file looked like before your changes.

What can you actually do with those snapshots? Quite a lot. You can revert a file to any previous version with a single click — just pick the version you want and restore it. You can also download an older version as a brand new file, which is handy if you want to compare two drafts side by side without touching the current one. On top of that, Nextcloud keeps an activity log for each file, so you can see who changed what and when. That’s genuinely useful in a team environment where multiple people work on the same documents.

Now, versioning doesn’t come for free — it uses storage. By default, the system holds versions for up to thirty days, or up to fifty versions per file, whichever limit is reached first. Both of those numbers can be adjusted by an administrator.

Here’s where storage planning matters. The way to think about it is this: take your total active file storage, multiply it by the average number of versions you’re keeping per file, and that gives you the extra space versioning will consume on top of your normal storage. To put that in NZRT terms — if you have five hundred gigabytes of active documents, and each file has an average of five versions saved, you’re looking at an additional two and a half terabytes of storage overhead. That’s significant. For non-critical documents, the recommended approach is an aggressive cleanup schedule — clearing old versions every seven days rather than waiting out the full thirty-day window.

That brings us to trash, which works like a recycle bin. When you delete a file in Nextcloud, it doesn’t vanish immediately — it moves to the trash folder, giving you a window to recover it if you change your mind. Administrators can configure how long deleted files sit there before being permanently removed. The system can handle this automatically, letting Nextcloud decide based on available storage. There’s also a command-line tool admins can run to preview what would be cleaned up before anything is actually deleted — a dry run — so you can check what’s going before you commit to it.

For NZRT specifically, versioning is treated as critical infrastructure, not just a nice-to-have. The main reason is how tightly Nextcloud is woven into Dolibarr document workflows. Think about contract amendments — when a contract goes through multiple rounds of negotiation, each revision needs to be traceable. Invoice corrections, purchase order revisions — all of these benefit from a clear version trail. If something looks wrong on a document, you want to be able to pull up exactly what it said last Tuesday.

The EDM agent — you might know her as ema — is responsible for managing retention policies across NZRT’s document library. Different document types get treated differently. A working draft might be cleaned up aggressively to save space, while a signed contract or financial document gets a much longer retention window.

If you want to go deeper on any of this, the related areas to explore in the wiki are the Files App documentation, the occ Command Reference — which covers the command-line tools admins use to manage Nextcloud — and the Backups and Maintenance section.

The key takeaway is this: versioning and trash in Nextcloud are automatic safety nets, but they cost storage. Understanding your retention settings and planning your cleanup schedule is how you keep that cost under control without losing the ability to recover from mistakes.

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

000NCL, 02 - Collaboration Apps

Talk Chat Video

Welcome to the NZRT Wiki Podcast. Today we’re looking at 💬 Talk (Chat & Video).

So let’s set the scene. If you’ve ever wondered why NZRT isn’t using Slack for team chat or Zoom for video calls, this episode answers that question. The answer is Nextcloud Talk — a secure, self-hosted communication platform that lives entirely on NZRT’s own infrastructure. No third-party servers, no external subscriptions, and no data leaving the building, so to speak.

Nextcloud Talk covers the full range of communication you’d expect from any modern team tool. You’ve got direct messages for one-on-one encrypted conversations, group chats for teams, projects, or topics, and video and audio calls that can handle up to one hundred participants at a time. Those video calls run on WebRTC, which is an open, encrypted standard, so your calls are protected end to end. Beyond that, you can share your screen during calls — either your whole desktop or just a specific window — and you can record calls for later review. Notifications are covered too, whether that’s desktop alerts, email, or mobile push notifications.

Now let’s talk about how NZRT actually organises its channels in Talk. There are a few different types you’ll encounter. First, you have persistent channels — these are the always-on rooms that the whole team uses day to day. Think of channels for general conversation, team-wide announcements, and a dedicated tech channel. Then you have project-specific channels, which are spun up for focused work — things like a channel for a Dolibarr deployment, another for a WordPress redesign project, or one specifically for Nextcloud administration tasks. Third, you have direct messages, which are just your standard private one-on-one conversations. And finally, there are read-only channels, which are used for announcements — only the admin account, xc, can post in those, so they stay clean and authoritative.

Now, let’s look at how Talk is configured for NZRT’s specific needs. The settings used here cover a few important areas. The maximum number of participants in a call is set to fifty. Public calls are required to have a password before anyone can join. Call recording is switched on automatically — this is tied to NZRT’s Electronic Document Management requirements, meaning recordings are kept as part of the organisation’s compliance record. And speaking of compliance, recordings aren’t kept forever — they’re set to automatically delete after ninety days, keeping the archive manageable without losing anything that’s needed for audit purposes.

That combination of auto-record and timed expiry is worth understanding because it’s not just a housekeeping measure. The EDM function at NZRT — handled by the ema role — is responsible for records retention, and Talk feeds directly into that workflow. When a call finishes, the recording doesn’t just sit in someone’s downloads folder. It integrates with Nextcloud’s archival system, so it’s stored, managed, and eventually disposed of according to the retention policy. That’s a level of record-keeping that most external video platforms can’t give you without paying for enterprise add-ons.

And that brings us to the bigger picture of why Talk exists in the NZRT stack at all. Every Slack message on an external platform and every Zoom call lives on someone else’s server. For a consultancy that takes data sovereignty seriously, that’s a problem. By running Talk on NZRT’s own data centre infrastructure, all communications stay internal. There are no licensing fees for Slack seats or Zoom licences, and there’s no dependency on a third-party service going down or changing its pricing model. It’s a deliberate choice to own the stack.

If you want to explore related areas, the wiki connects Talk to a few other topics worth knowing about. The Collaboration Overview gives you the broader picture of how NZRT’s tools fit together. The Users and Groups page explains how access is managed across Nextcloud, which naturally affects who can join which Talk channels. And the Email and CalDAV CardDAV note covers the other communication channels that sit alongside Talk in the stack.

So to summarise what you’ve learned today: Nextcloud Talk is NZRT’s all-in-one, self-hosted replacement for Slack and Zoom. It supports direct messages, group channels, encrypted video calls for up to one hundred people, screen sharing, and call recording. NZRT’s channels are organised into persistent team rooms, project-specific rooms, direct messages, and read-only announcement channels. Calls are configured to require passwords, auto-record for compliance, and delete recordings after ninety days. And the whole system feeds into the ema role’s records retention workflow, keeping NZRT audit-ready without relying on any external platform.

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

000NCL, 03 - Document Management

Tagging Search

Welcome to the NZRT Wiki Podcast. Today we’re looking at Nextcloud Tagging & Search.

If you’ve ever dug through a shared drive looking for one specific contract or invoice and come up empty, this episode is for you. Nextcloud’s tagging and search features exist to solve exactly that problem — helping everyone at NZRT find documents quickly, stay organized, and meet record retention requirements without a lot of manual hunting.

Let’s start with the tag system. At NZRT, tags aren’t just freeform labels — admins create and maintain a standardized set so that everyone is tagging consistently. There are eight standard tags you’ll encounter across the vault, and each one has a defined purpose and a specific set of people responsible for applying it.

The first is “invoice,” which you’d apply to financial documents. That one is handled by our Finance agent and xc. Next is “contract,” used for legal agreements, applied by our Client & Strategy agent and xc. Then there’s “draft,” which marks anything still in progress — and that one is for everyone to use, not just a specific role.

Once something has been signed off or finalized, it gets the “approved” tag, and that’s applied by xc, Finance, or Client & Strategy depending on the document. The “confidential” tag marks restricted access files and is controlled by xc and our Handling agent. If a document has been synced across to the Dolibarr ERP system, it gets tagged “dolibarr,” and that’s managed by our Email & Integration agent and xc. Similarly, blog and website content gets a “wordpress” tag, applied by the Email and Publishing agents. And finally, anything heading into long-term storage picks up the “archive” tag, courtesy of our Data agent or xc.

So those eight tags give you a clean, shared vocabulary across the whole team. Instead of everyone inventing their own labels, you’ve got a consistent layer of metadata that makes searching reliable.

Speaking of searching — let’s talk about how the full-text search capability works under the hood. There’s a configuration step that enables the full-text search feature in Nextcloud. In plain terms, two extensions get switched on: one that provides the search interface inside Nextcloud itself, and one that connects it to Elasticsearch, which is the underlying search engine doing the heavy lifting. Once those are active, you run an indexing command that goes through all your existing documents and makes their contents searchable. So it’s not just searching file names — it’s looking inside PDFs, Word documents, and other files to find the actual words you’re looking for.

Once that’s set up, you can run some pretty powerful queries. Think of these like structured search requests. For example, you could search for all invoices from 2026 that were tagged by the Finance role — the system would return every document matching all three of those criteria at once. Or you could ask for all approved contract PDFs — filtering by file type, tag, and approval status simultaneously. You’re essentially layering filters together rather than doing one broad search and then manually sifting through results.

Now, why does all of this matter in the NZRT context? Tagging is tied directly to compliance. When documents are consistently tagged, it becomes much easier to apply and verify record retention policies — you know what’s been approved, what’s still a draft, what’s confidential, and what’s been archived. Without that consistency, things slip through the cracks.

There are also two agents with specific roles in keeping this system healthy. EDM — that’s our Email and Integration agent, ema — manages the tag hierarchy itself. So if you think a new tag should be added or an existing one needs changing, that goes through ema. And our Data agent, dai, uses tags as part of reporting and analytics work — so good tagging discipline directly feeds into the quality of the data that drives decisions.

If you want to go deeper, there are a few related topics worth exploring in the wiki. Document Management Overview gives you the broader picture of how files are structured and governed. The Files App article covers the day-to-day interface you’re working in. And NZRT Folder Structure explains how the directory layout is set up, which pairs naturally with tagging to give you both location-based and label-based ways to find what you need.

The short version: tag consistently using the standard set, use the search system to filter across multiple criteria at once, and you’ll spend a lot less time hunting for documents and a lot more time actually working with them.

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

000OBS, 03 - Plugins

Core Plugins

Welcome to the NZRT Wiki Podcast. Today we’re looking at Core Plugins.

If you use Obsidian as part of your workflow at NZRT, you’ve probably noticed that it comes with a set of built-in plugins right out of the box. These are called core plugins, and they’re maintained by the Obsidian team themselves. You can turn any of them on or off for your vault by going into Settings and then selecting Core plugins. So let’s walk through what’s available and what each one does.

Starting with the ones that are switched on by default. Backlinks gives you a panel showing every note in your vault that links to the note you’re currently reading, including any mentions that aren’t formally linked yet. Bookmarks lets you star notes, folders, searches, and even specific headings so you can get back to them quickly. Canvas is Obsidian’s infinite whiteboard — you can arrange notes, cards, and images spatially, which is great for visualising how ideas connect. Command palette, which you open with Control and P, lets you run any Obsidian command just by typing part of its name. File recovery runs automatic snapshots of your vault every five minutes, so if you accidentally delete something, you can get it back. Files gives you the standard file explorer sidebar. Graph view lets you see a visual map of how all your notes connect to each other. Outgoing links shows you all the wikilinks inside your current note, including ones that don’t resolve to an existing file yet. Outline gives you a heading navigator for whatever note you have open. Page preview lets you hover over a wikilink while holding Control to peek at the target note without actually navigating away. Properties view is a global panel that lets you browse all the frontmatter keys used across your entire vault. Quick switcher, opened with Control and O, lets you jump to any note by typing part of its name. Search, which you open with Control, Shift, and F, gives you full-text search across your vault with operator support. Tags view shows you all your tags with note counts beside them, and you can click a tag to search by it. And finally, Word count displays word and character counts in the status bar at the bottom of the screen.

Now for the plugins that are off by default but available to enable. Audio recorder lets you record audio directly into a note. Daily notes automatically creates a dated note for each day and gives you a quick shortcut to open today’s. Format converter helps you migrate Markdown-style links over to Obsidian’s wikilink format. Note composer lets you merge notes together or extract a selection into a brand new note. Random note opens a random note from your vault, which is handy if you use spaced repetition for review. Slash commands let you type a forward slash inside the editor to trigger commands inline without leaving your keyboard. Slides turns a note into a slideshow presentation. Templates lets you insert template files into your current note. Unique note creator generates notes with unique ID-based filenames rather than regular titles. And Workspaces lets you save and restore your entire pane and tab layout as named configurations, so you can switch between different working setups easily.

A few of these plugins have settings worth knowing about. For Daily notes, you’ll want to set a folder, a template file, and your preferred date format — the standard here is four-digit year, two-digit month, two-digit day. For File recovery, you can adjust how often snapshots are taken and how long they’re kept. To actually access your snapshots, go to Settings, then File recovery, then View snapshots. For Templates, you set the folder path where your template files live, and you can insert a template using Control and T, or through the Command palette.

For Search, there’s a set of operators that make your queries much more powerful. You can search for notes that carry a specific tag by typing the tag name with a hash symbol. You can narrow results to a specific folder by typing the folder path. You can search by filename. You can match a specific frontmatter field by putting the field name and value inside square brackets. And you can even run a regular expression search by wrapping your pattern in forward slashes.

That covers everything in the Core plugins reference for Obsidian. Whether you’re just getting started with your vault or looking to tighten up your workflow, knowing which of these tools are available — and which ones you need to switch on — is a solid place to start.

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

000OBS, 02 - Interface

Editor Modes

Welcome to the NZRT Wiki Podcast. Today we’re looking at Editor Modes.

If you use Obsidian to manage your notes and documentation, you’ve probably noticed there are a few different ways to view and edit a note. Obsidian gives you three distinct modes, and knowing when to use each one can make a real difference to how smoothly you work.

Let’s start with the big picture. The three modes are Live Preview, Source Mode, and Reading View. You can switch between them on a per-note basis, or you can set a default in your Settings so every new note opens the way you prefer.

The first mode is Live Preview, and this is the default. Think of it as the best of both worlds. You’re writing in markdown, but Obsidian renders your formatting as you go. So if you bold some text, the asterisks disappear and you instantly see bold text right there in the editor. Links look like clickable links rather than showing the raw bracket syntax. Headers jump up in size as soon as you finish typing them. It gives you a clean, almost word-processor feel while still working in plain markdown underneath.

The second mode is Source Mode. This is where you see everything — all the raw markdown syntax exactly as written. Bold text shows the asterisks on both sides. Links show their full bracket and parenthesis structure. Headers show the hash symbols out front. Nothing is hidden or rendered. This mode is especially useful when you need to do precise editing — for example, if you’re troubleshooting why some formatting isn’t working, or you need to copy raw syntax without Obsidian processing it.

The third mode is Reading View. This is fully rendered and read-only. You can’t edit in this mode — it’s purely for reading your finished note as it would look when published or shared. Everything is formatted, links are clickable, and no markdown syntax is visible at all.

So how do you switch between them? The keyboard shortcut Control and E toggles you between your current editing mode and Reading View. To switch specifically between Live Preview and Source Mode while you’re already in the editor, you go to the three-dot menu in the top right corner of the note and choose Toggle Source Mode.

If you want to set a default so all your notes open in a particular mode, go to Settings, then Editor, and look for Default Editing Mode. You can pick either Live Preview or Source Mode there, and that preference applies across your entire vault.

There are also a couple of other editor settings worth knowing about. If you’re a Vim user — that’s a keyboard-driven editing style where you switch between different modes like insert and normal — Obsidian has you covered. Go to Settings, then Editor, and you’ll find a Vim Key Bindings toggle. Switch that on and you get the classic Vim experience: press i to enter insert mode and start typing, press Escape to return to normal mode, and all the standard Vim navigation shortcuts work exactly as you’d expect. There’s also a community plugin called Vimrc Support, which lets you load a custom configuration file to tailor your Vim setup even further.

Finally, spellcheck. You’ll find it under Settings, then Editor — it’s a simple on and off toggle. When it’s on, Obsidian underlines words it thinks are misspelled, and right-clicking on an underlined word gives you suggestions. The language is set per vault, so if you’re running multiple vaults in different languages, each one can have its own setting.

So to recap: Live Preview is your everyday writing mode where formatting renders as you type. Source Mode is for when you need to see and edit the raw markdown directly. And Reading View is for when you just want to read without making any changes. Use Control E to flip between editing and reading, and head into Settings then Editor to lock in your defaults and any extras like Vim or spellcheck.

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

000OBS, 01 - Core Concepts

Frontmatter Properties

Welcome to the NZRT Wiki Podcast. Today we’re looking at Frontmatter & Properties.

So, what is frontmatter? At its core, frontmatter is a block of structured metadata that sits at the very top of an Obsidian note. It’s written in a format called YAML, and it’s wrapped between two sets of triple dashes — one at the very start, one at the end of the block. Think of it as a label on a folder: it tells you and your tools what’s inside, without being part of the actual content.

That block of metadata is queryable by a plugin called Dataview, and it’s also filterable in Obsidian’s search. So it’s not just decoration — it’s functional.

Let’s talk about what that looks like in practice. The code example in the wiki shows a frontmatter block containing five fields. You’ve got a tags field holding two tag values. An aliases field with two alternative names for the note. A created date set to the twenty-fifth of May 2026. A status field set to active. And a type field set to reference. The key rule here: this block must appear at the absolute top of your file. There can’t be a blank line before that opening set of triple dashes — it has to be the very first thing in the document.

Now, if you’d rather not hand-edit that raw YAML, Obsidian version 1.4 and above gives you a much friendlier way to work with it. It’s called the Properties panel. You can open it by pressing Control and the semicolon key together, or by going to View and selecting Toggle Properties. What you’ll see is a clean graphical interface where all your frontmatter fields appear as typed input boxes — no angle brackets, no colons, no syntax to worry about. You just click and type.

That brings us to data types, and there are seven of them to be aware of. First is plain text — something like a title field containing a note name. Second is a number, useful for things like a priority field where you’d enter a digit. Third is a checkbox, which maps to a true or false value — handy for a done field. Fourth is a date, displayed as a date picker in the Properties panel. Fifth is date and time combined, which lets you capture both the day and a specific time, like ten thirty in the morning. Sixth is a list, where you can store multiple values in a single field — tags being the most common example. And seventh is a wikilink, which lets you link directly to another note from within your frontmatter.

There are also three built-in fields that Obsidian itself understands and acts on. The first is tags, which tags your note the same way an inline hashtag would in the body of the document. The second is aliases — this lets you give a note alternative names, and those names show up in link autocomplete and search results, so other notes can reference it by a different label. The third is cssclasses, which lets you apply custom CSS styling to a specific note. Everything beyond those three is user-defined, and only carries meaning if a plugin like Dataview or Templater knows to look for it — or if you’re using it for your own personal organisation system.

Speaking of Dataview — let’s talk about how you actually use frontmatter fields in a query. The example in the wiki shows a table query that pulls two fields, status and created, from notes inside a folder called Projects. It then filters to only show notes where the status field equals active, and sorts the results by the created date in descending order, so the most recent ones appear first. In plain terms: you’re asking Dataview to build a live table of your active project notes, newest at the top. Any frontmatter field you’ve defined can be used the same way — filtered, sorted, or displayed as a column.

Finally, there’s Obsidian’s built-in search. You can target frontmatter fields directly by wrapping them in square brackets with a colon between the field name and the value. For example, searching for status colon active inside square brackets finds every note where the status field is set to active. Searching for tags colon the code 000OBS inside square brackets finds every note tagged with that identifier. It’s a precise way to filter your vault without needing to run a full Dataview query.

So to recap: frontmatter sits at the top of your note, stores structured metadata in YAML format, supports seven data types, has three built-in fields Obsidian acts on natively, and can be edited either as raw text or through the Properties panel GUI. Plugins like Dataview can query it, and Obsidian’s search can filter by it directly.

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

00 - Overview, 000OBS

Obsidian Overview

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

So, what is Obsidian? At its core, Obsidian is a local-first markdown knowledge base. What that means in plain terms is that your notes live as plain text files right on your own disk. No cloud account required, no proprietary format, and no lock-in. If you ever decide to stop using Obsidian, your files are still there, readable by any text editor on any computer. That’s a pretty important distinction from a lot of the popular note-taking tools out there today.

Let’s talk about the philosophy behind Obsidian, because it shapes everything about how it works. There are five core principles worth knowing. First, it’s local-first — your files sit on your disk as plain markdown files, always accessible. Second, it uses plain text. There’s no database running in the background, no binary format that locks your data away. Your notes are designed to survive any app changes, now or in the future. Third, Obsidian is built around the idea of interconnected notes. You create links between your notes using what are called wikilinks, and over time that builds a web of knowledge. There’s even a graph view that visually shows you how all your notes connect to each other, which is genuinely useful once your vault grows. Fourth, Obsidian is highly extensible. There’s a rich plugin ecosystem that lets you add functionality without bloating the core application. And fifth, it works fully offline. Syncing across devices is optional and completely separate from the core app.

Now, it’s just as useful to know what Obsidian is not, so you can set expectations correctly. It’s not a cloud note app like Notion or Evernote — there’s no built-in sync required. It’s not a task manager, though plugins can add that capability if you want it. It’s not a word processor — you’re working in markdown throughout. And it’s not a database, although there’s a popular plugin called Dataview that adds query capabilities if you need them.

Let’s cover editions and pricing, because this is something people often ask about. There are five tiers to be aware of. The Personal edition is completely free and gives you the full app, unlimited notes, and all core features. If you want early access to what they call Insider builds — basically beta versions of the app — there’s a one-time payment of around twenty-five dollars for what’s called the Catalyst tier, which also comes with a supporter badge. Beyond that, there are two optional paid services. Obsidian Sync costs ten dollars a month and gives you end-to-end encrypted sync across your devices using Obsidian’s own servers. Obsidian Publish costs twenty dollars a month and lets you publish your vault as a public website. And finally, there’s a Commercial licence at fifty dollars per user per year, which is required if you’re using Obsidian for business purposes — specifically, if your organisation has more than two employees or brings in more than one million dollars in revenue.

One thing worth highlighting about those paid services: Sync and Publish are entirely optional. If you don’t want to pay for Obsidian Sync, you can absolutely replace it with tools you might already have — Nextcloud, iCloud, Dropbox, or even Git. The app doesn’t care how you sync your files, because they’re just plain files on your disk.

In terms of platform support, Obsidian runs on Windows, macOS, Linux, iOS, and Android. So you’re covered across all major platforms. One practical tip here: if you’re syncing across devices, make sure you include the dot-obsidian folder in your sync. That folder holds your settings, plugins, and themes, so including it means your setup travels with you across devices without having to reconfigure everything.

Finally, on versioning — Obsidian uses a rolling release model, meaning it updates continuously rather than in big numbered versions. If you ever need to check what version you’re on, you can find it under Settings and then About. And if you’re a Catalyst supporter, you can opt into Insider builds from that same settings area to get early access to new features.

So to wrap it all up — Obsidian is a powerful, privacy-respecting, offline-first tool for building a personal knowledge base. Its strength is in its simplicity and longevity: plain text files, no lock-in, and a plugin ecosystem that lets it grow with your needs. Whether you use the free Personal edition forever or layer on Sync and Publish later, the foundation stays the same — your notes, your files, your control.

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

000OBS, 04 - Settings & Themes

Settings Overview

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

If you’re using Obsidian, one of the first things worth knowing is where everything lives. All your settings are stored per-vault, meaning each vault you create has its own independent configuration. That configuration lives in a hidden folder called dot-obsidian, sitting right inside your vault directory. You can get to your settings at any time by pressing Control and comma together, or by clicking the gear icon in the bottom left of the interface.

Let’s walk through the main sections you’ll find in there.

The first section is Editor. This is where you control things like your default editing mode, how wide your lines are, what font size you prefer, whether you want vim keybindings, spellcheck, and whether brackets automatically pair up when you type them.

Next is Files and Links — and this one is particularly important, so we’ll come back to it in a moment.

Then there’s Appearance, which is where you pick your theme, set your font, switch between light and dark colour schemes, and even load custom CSS if you want to go further with visual customisation.

Hotkeys lets you remap any command in Obsidian to a keyboard shortcut of your choosing — again, we’ll cover the key defaults shortly.

After that you’ve got Core Plugins, where you can enable or disable Obsidian’s built-in functionality, and Community Plugins, which is where you’ll find the restricted mode toggle, the plugin browser, and any plugins you’ve already installed from the community library.

So let’s zoom in on Files and Links, because the choices you make here have a big impact on how your vault behaves day to day.

The first setting is where new notes get created. You have three options: the vault root, the same folder as the note you’re currently in, or a specific folder you define yourself. The recommendation here is to go with a specified folder, so new notes don’t just scatter randomly across your vault.

Next is wikilink format, which controls how Obsidian writes links when you reference other notes. Your options are shortest path, relative path, or absolute path from the vault root. Absolute from the vault root is the recommended choice — it keeps links consistent and less likely to break when you move files around.

There’s also a toggle for whether to use wikilinks at all, and the recommendation is to keep that switched on. Auto update internal links is another one worth keeping enabled — when you rename a note, Obsidian will automatically update every link pointing to it across your whole vault, which saves a lot of manual fixing later. And if you’re storing non-Markdown files in your vault, turning on Detect all file extensions means Obsidian will recognise and work with those as well.

Now let’s talk hotkeys. You can remap any command through Settings and then Hotkeys — just search for the command by name and click to assign your shortcut.

Out of the box, here are the defaults you’ll use most often. The Command Palette opens with Control and P. The Quick Switcher, which lets you jump to any note fast, is Control and O. Search across the whole vault is Control, Shift and F. New Note is Control and N. Toggling between edit and read mode is Control and E. Opening the graph view is Control and G. Getting back into Settings is Control and comma. Closing a pane is Control and W. One worth noting — splitting a pane to the right has no default shortcut assigned, so if you use that feature regularly, you’ll want to set one yourself through the Hotkeys section.

Finally, let’s cover where the config actually lives on disk, in case you need to back it up or sync it across devices. On Windows, macOS, and Linux, the answer is the same — it’s a folder called dot-obsidian sitting inside your vault directory. The platform path looks slightly different on each system, but the location relative to your vault is identical.

If you’re syncing your vault using something like Nextcloud or Git, you can include that dot-obsidian folder in your sync to carry all your settings across to other devices. One tip though — there’s a file in there called workspace dot json that stores your current pane layout. If you work across multiple machines with different screen sizes or setups, you’ll want to exclude that file from sync, otherwise your layout may get overwritten every time you switch devices.

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

000OBS, 01 - Core Concepts

Tags

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

So what are tags in Obsidian? Simply put, tags are a way to categorise your notes so you can filter and search across them easily. And the good news is that Obsidian gives you two ways to add them, and both work exactly the same under the hood.

The first way is inline tagging, meaning you drop a tag right into the body of your note. You just type a hash symbol followed by a word, like hash-project or hash-status-active. The second way is through frontmatter, which is the block of metadata at the very top of your note. There you’d write something like tags, colon, and then list your tags in square brackets separated by commas. Both approaches are indexed identically by Obsidian, so it doesn’t matter which you use from a search perspective. That said, frontmatter tags are the preferred approach for structured notes because it keeps your note body clean and uncluttered.

Now let’s talk about nested tags, which are really useful once your vault starts to grow. You create a nested tag by putting a forward slash between levels. So for example you might have a tag for area-work, another for area-personal, and then status-active and status-archived. What this does is create a hierarchy. In the Tags panel on the left sidebar, those nested tags fold neatly under their parent. And here’s the handy part when it comes to searching: if you search for area, Obsidian will match everything under that parent, so all of your area-work and area-personal notes come back in one go. You don’t have to search each sub-tag individually.

Speaking of the Tags panel, you can find it in the left sidebar by clicking the Tags icon. It gives you a full list of every tag used across your entire vault, along with a count of how many notes carry each one. Click any tag in that panel and Obsidian immediately opens a search showing all the notes that use it.

Now let’s cover searching with tags directly, because there are a few different ways to do it. If you just type a hash followed by your tag word in the search bar, you’ll get notes that contain that tag inline in the body. If you want to catch tags whether they’re in the frontmatter or inline, you prefix your query with tag-colon and then your hash and tag name. And if you want to search across an entire nested tag family, you can type tag-colon, hash, your parent tag name, and then a forward slash, and Obsidian will return every note tagged with anything under that parent.

Finally, it’s worth understanding the difference between tags and folders, because you’ll be using both in a well-organised vault. There are a few key differences to keep in mind. With folders, a note lives in exactly one place on your filesystem. With tags, a single note can carry as many tags as you like. Folders give you a hierarchical, physical organisation structure. Tags give you cross-cutting categorisation that cuts across those folder boundaries. Both are queryable through Dataview, although the syntax differs slightly: for folders you use a FROM clause pointing to the folder path, while tags just filter by tag name. The practical takeaway is to use folders as your primary organisation method and tags for attributes that span multiple folders, things like status, note type, or service codes.

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

000OBS, 01 - Core Concepts

Wikilinks Backlinks

Welcome to the NZRT Wiki Podcast. Today we’re looking at Wikilinks & Backlinks.

If you use Obsidian as your knowledge base, wikilinks are probably the feature you’ll reach for the most. Every link you create is bidirectional — meaning the note you’re linking to automatically knows it’s been referenced. That’s what makes Obsidian’s knowledge graph so powerful, and it all starts with understanding the syntax.

The wiki lays out eight different ways to create a wikilink, so let me walk you through them in plain language.

The simplest form is just wrapping a note’s filename in double square brackets. That creates a direct link to that note by name. If you want the link to display different text to the reader — say you want it to read “our onboarding guide” but it actually points to a note called New Staff Process 2026 — you can add a separator between the note name and the display text you want shown. The link works the same way, it just looks different on screen.

If you want to be more precise about which note you’re pointing to — which is a good idea in larger vaults where notes in different folders might share similar names — you can include the full folder path from the vault root, not just the filename.

You can also link to a specific section inside a note rather than the whole thing. By appending the heading name after the note name, Obsidian will jump straight to that heading when you follow the link. There’s also a block-level version of this — instead of a heading, you link to a specific paragraph or list item using a block identifier that Obsidian generates for you.

Then there are embed links. These are a step beyond regular links — instead of just pointing to a note, they pull that content directly into the current page inline. You can embed a full note, just a specific section of a note, or an image file. All three work the same way, just with a different target.

Now let’s talk about how Obsidian figures out which note you mean when you write a link. It follows a two-step process. First, it looks for an exact path match from the vault root. If it doesn’t find one, it searches for any note with that filename anywhere in the vault, and if there are multiple matches it picks the one with the shortest path. To avoid ambiguity — especially as your vault grows — the recommendation is to always use the full path from the vault root.

Next up is one of the most useful features Obsidian offers: the Backlinks panel. You’ll find this in the right sidebar of any note, and it shows you two things. First, linked mentions — notes that have explicitly created a wikilink pointing to the note you’re currently reading. Second, unlinked mentions — notes that mention your note’s title as plain text, without a formal link. That second category is particularly useful for finding connections you haven’t formalised yet. To enable it, go to Settings, then Core Plugins, and switch on Backlinks.

There’s also the Outgoing Links panel, which works the other way around. While backlinks show you what points to the current note, outgoing links shows you everything the current note points to. It breaks these down into resolved links — where the target note exists — and unresolved links, where the target hasn’t been created yet. Unresolved links appear in a different colour and show up as what the wiki calls a ghost node in the graph view. So even a link to a note that doesn’t exist yet leaves a visible mark, which can be a handy way to spot gaps in your knowledge base.

When you’re writing and want to insert a link, you trigger the autocomplete picker by typing two opening square brackets. This opens a fuzzy search across all your note titles, so you don’t need to type the exact name — just enough of it for Obsidian to recognise it. You can press Tab to accept a suggestion or Enter to open the note directly.

Finally, there’s Page Preview. If you hold the Control key and hover your mouse over any wikilink, a popup appears showing you that linked note’s content — without navigating away from what you’re currently reading. This requires the Page Preview core plugin to be enabled, which you’ll find alongside the others in Settings.

So that’s the full picture of wikilinks and backlinks in Obsidian — from creating links and embedding content, right through to understanding how the graph connects everything together.

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

000WOR, Text

Togaf Application Platform Service Categories

Welcome to the NZRT Wiki Podcast. Today we’re looking at Togaf Application Platform Service Categories.

If you’ve ever wondered what sits underneath an enterprise architecture — what kinds of services an application platform actually needs to provide — this episode breaks that down for you. TOGAF defines a comprehensive set of service categories, and together they describe every major capability a platform must support. Let’s walk through them one by one.

We start with Data Interchange Services. These cover how data moves and transforms between systems. Think document typing and conversion, graphics interchange, electronic data interchange, fax services, and raw graphics interface functions. It also includes text processing, document processing, publishing, video, audio, and multimedia processing functions, along with media synchronisation, information presentation and distribution, and hypertext functions. Essentially, anything to do with getting data from one form or place to another.

Next are Database Management System services. These include object-oriented database management, file management, query processing, screen and report generation, networking and concurrent access, and data warehousing. These are the services that let your platform store, retrieve, and present structured data.

Graphics and Imaging Services cover graphical object management, drawing services, and imaging functions. If your platform needs to render or manipulate visual content, this is the category that supports it.

Location and Directory Services are all about finding things. Directory services, special-purpose naming, service location, registration, filtering, and accounting services all live here. These help systems and users locate resources across a network.

Network Services are broad. They cover data communications, electronic mail, distributed data and file services, distributed naming and time services, remote process access, and remote print spooling. On top of that, you’ve got enhanced telephony, shared screen functions, video conferencing, broadcast functions, and mailing list functions. This category is the backbone of how distributed systems talk to each other.

Operating System Services keep things running at the foundation. Kernel operations, command interpreter and utility services, batch processing, and file and directory synchronisation services all sit here.

Software Engineering Services support how software is built. This includes programming language services, object code linking, computer-aided software engineering tools, graphical user interface building, scripting languages, language bindings, run-time environments, and application binary interface services. If you’re building or deploying software on the platform, these services are what you depend on.

User Interface Services are what users actually interact with. Graphical client and server services, display objects, dialogue support, printing, computer-based training and online help, and character-based services all fall into this category. This is where the platform meets the person.

Security Services are critical. You’ve got identification and authentication, system entry control, audit services, access control, non-repudiation, security management, trusted recovery, encryption, and trusted communication services. Together these ensure that only the right people and systems can do the right things, and that there’s a record when they do.

System and Network Management Services cover the operational side of keeping everything running. User management, configuration management, performance management, availability and fault management, accounting management, print management, network management, backup and restore, online disk management, licence management, capacity management, software installation, and trouble ticketing services. This is your operations team’s toolkit, built into the platform definition itself.

Finally, Object Request Broker Services handle distributed object communication. These include implementation repository services, installation and activation, interface repository services, and replication. Then there’s a rich set of common object services covering change management, collections, concurrency control, event management, externalisation, licensing, lifecycle management, naming, persistent object services, properties, query services, relationship services, start-up services, time services, trading services, and transaction services. This category is what lets distributed components find each other, communicate reliably, and maintain consistency across a system.

So when you look at all of these together — eleven major categories, hundreds of individual service types — you get a picture of just how comprehensive the TOGAF application platform model is. It’s not just about what your application does. It’s about every layer of capability the platform must provide to make that application possible.

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