Sarah from procurement opens her laptop on a Tuesday with one item on her mind: the IT support contract is up for renewal in 90 days. Three things have to happen between now and then. The renewal review meeting needs a calendar slot. Pricing benchmarks need gathering. The SLA performance from the last twelve months needs reviewing — and that's a job for Tom on the service desk, not her. Oh, and there was that incident last month where the supplier missed an SLA. Was that ever properly resolved?
Four things to do, four different modules. In a tool where each one is its own island, Sarah is about to spend the next hour copy-pasting contract numbers into task descriptions, manually creating a calendar event from scratch, and hoping she remembers what she scheduled when the day comes around.
That's the wrong shape for the work.
FreeITSM is built around a different assumption: that work doesn't really live in modules. It lives in the connections between them. A contract renewal isn't a "Contracts thing" or a "Calendar thing" — it's both, plus several tasks, plus a couple of historic tickets, all sitting around the same supplier relationship. The job of the platform is to keep all of that wired together so the analyst's attention can move between contexts without dropping the thread.
This piece is about that wiring. Specifically: how the four modules an analyst touches most days — Tickets, Tasks, Calendar, and Contracts — reach into each other, what each one is good at, and why the seams between them are first-class instead of an afterthought.
Each module, one question
The cleanest way to think about the four modules is to ask what question each one is built to answer. They're more useful when their jobs are kept distinct.
Who is involved, for how long, and on what terms?
→ Calendar (review meetings, notice deadlines)
What's broken right now, and who's looking at it?
What needs doing, by whom, by when?
(a task always knows its parent context)
When does it happen?
← Change Management (scheduled windows)
Each module is a different question. The links are how the answer travels.
Notice that the links aren't just hyperlinks — they're foreign keys on the underlying data. A task that's linked to a contract isn't a task with a stray contract number in its description; it's a task whose contract_id column points at that contract row. That distinction matters. Free-text references rot. They don't survive renames, they don't show up on filter pages, and they don't let the contract page list its own related work. Foreign-key links survive everything, work in both directions, and cascade cleanly when something is deleted (the ON DELETE SET NULL behaviour means a deleted contract leaves its old tasks and events alive but unlinked, instead of vapourising them).
What the wiring looks like in practice
Take Sarah's morning. Here's the actual click path, top to bottom:
Three things to notice. First, every link in that diagram is created with a button click on the contract page — the contract view in FreeITSM has a Task button and a Calendar button right in its header that open lightweight modals with sensible defaults pre-filled (title using the contract number, due date using the notice date, assignee using the contract owner). Sarah doesn't navigate to the Tasks module to type in the contract number. The link is a side-effect of where she made the thing.
Second, when Tom logs in tomorrow morning, his Tasks board shows "Review SLA performance for IT-2024-09" sitting in his "To Do" column. Click into it and the contract is right there in the linked-context block, one hop away. He doesn't need a briefing email; the context travelled with the work.
Third, when Sarah revisits the contract page two weeks later, the Related Tasks panel shows both her task and Tom's, with their current status pills. She can see Tom is already "In Progress" without going anywhere. The renewal-review event is in the Related Calendar Events panel. The whole picture lives on one page.
The view from each module
A bidirectional link is only useful if both ends of it are visible. So FreeITSM surfaces the connection on both sides:
- From a contract, two panels at the bottom of the view page list every task and every calendar event linked to that contract, with status pills, assignees, and due dates.
- From a task, the linked context (ticket, change, or contract) is shown alongside the task's own fields, with a click-through to the parent.
- From a ticket, the child tasks are listed inline so the analyst can see what work has been spun out and where it stands.
- From the calendar, an event linked to a contract just looks like a normal event — but it carries the link and click-through.
The point is that no single module monopolises the relationship. You can land on any of the four endpoints and walk the wiring outward.
Why not workflow automation?
The natural next question is: if the system knows a contract is 90 days from renewal, why not have it auto-create a renewal-review task assigned to the contract owner? Wouldn't that be even better than a button on the contract page?
Maybe. But probably not, and FreeITSM deliberately doesn't ship it. The reason: real teams differ wildly in what to do, when to do it, and who owns it. One team wants 90/60/30 day reminders cascading into different escalation tasks. Another wants nothing automatic at all because their contracts vary too much. A third wants a pre-renewal RFP kicked off at 180 days but only for contracts above a value threshold. There is no template that fits more than one of those teams without driving the other two mad.
Don't build the workflow engine. Build the wiring.
So FreeITSM's design choice is to make the wiring first-class — the links between modules are as native as the modules themselves — and to delegate the prompting to Watchtower, which goes amber on a contract at 90 days and red at 30. The analyst sees the prompt, decides what to do, and the wiring is right there to capture whatever they choose. If automation gets bolted on later, it builds on the wiring; the wiring doesn't depend on the automation.
The supplier-shaped view
One quietly powerful consequence of the contract being the natural anchor for tasks and events: the contract page becomes the closest thing the platform has to a supplier dashboard. Open the contract for IT-2024-09, and inside two scrolls you've got everything you need to know about that supplier relationship right now — the dates, the financials, the terms, every piece of work currently linked to it, every event coming up. Add the supplier's open and historic tickets (one click away from the contract, via the supplier link) and you've covered the surface area completely.
Most ITSM tools either don't do supplier views at all, or do them as a separate module with yet another navigation tree. FreeITSM gets one for free as a side-effect of putting links in the right places.
What this changes for you
The headline change is small but adds up. Without the wiring, every cross-module action costs a context switch — navigate, search, copy, paste, save, navigate back. With the wiring, the action is a button on the page you're already on, and the link is recorded automatically. Multiply that by every contract review, every ticket-spawned subtask, every renewal meeting in your calendar, and the time saved over a quarter is real.
The deeper change is harder to see but matters more: nothing falls between the cracks. The work that used to live in someone's head — "I think there was a ticket about this supplier last month" — now lives in the data, reachable in one click from anywhere relevant. Six months later, when the next analyst inherits the contract, the whole history of related work comes attached. They don't have to go archaeology hunting; the wiring tells them.
That's what connected modules actually buy you. Not a fancier UI. Not workflow automation. Just the boring, durable property that the work knows where it belongs, no matter how often it moves between contexts.