By ITFlow

ITFlow

What it does

ITFlow is a free, open-source platform for small managed service providers that want client IT documentation, tickets and billing in one place. A team can record a client's devices and services, connect a support request to that context, assign work, and keep a resolution history. Its breadth helps when those records are maintained together, but a buyer should choose which modules and integrations the team actually needs.

Last updated
Oct 20, 2026
ITFlow · Editorial illustration
Conceptual editorial illustration of a client device records moving through a service ticket to a resolved case folder.

Work at ITFlow?

Help customers find accurate information about your software.

Manage this listing →

Find your fit

Who it is for

A small MSP can use ITFlow to organize each customer's contacts, locations, assets and infrastructure records before support issues arrive. It is especially relevant when technicians need to see both the ticket and the associated device or service while working.

The product also covers invoicing and a client portal. These can simplify handoffs between service and administration, but an MSP using only documentation or tickets can disable unused modules and add integrations gradually.

Back to sections

The work it supports

Core capabilities

Start with a client record, then add contacts and locations. The assets module can record laptops, servers and network gear with status, model and serial information. Link each relevant asset to its location, network, service and later tickets so a technician has context during a request.

A service record can group information about a client's infrastructure or application, including client contacts, vendors, documents and assets. Use it as a practical runbook index for a service the MSP supports, and decide which entries require restricted access.

Tickets carry client/contact, priority, status and related asset information. Agents can assign work, track time and leave internal notes. Rehearse an issue that changes owner or priority so the team can see how the work and its history move.

The docs distinguish a resolved ticket from a closed one. A resolved ticket can be reopened by an agent or client contact during a configurable period; a closed ticket cannot. Set that policy to match the MSP's follow-up process before importing active requests.

Configured email notifications can alert clients and agents about ticket events. The client portal lets contacts open and track requests; local login or optional Azure AD SSO is available. Test a client contact's view so one customer's tickets and documents do not cross into another account.

ITFlow 26.08 or newer adds optional SLA plans with response and resolution targets. They remain inactive until assigned; warning and breach alerts need scheduled jobs, and email alerts need mail configuration. Pilot one priority and business-hours schedule before promising a target to a customer.

Recurring invoices, client review and payment tracking sit beside service work. The docs mention Stripe for one-off and recurring payment collection; confirm the billing workflow and payment integration separately from ticket handling.

Back to sections

Understand the offer

Pricing and getting started

The project describes ITFlow as free and open source. The installation guide is for a self-managed system, recommending Debian Linux, Apache, MariaDB and PHP. Account for server hosting, administration, updates and backups even when the software license has no charge.

The guide recommends its Debian installation script and labels the Docker route community supported. It warns that other installation paths may receive limited support. Choose the deployment method the MSP can maintain and verify the current requirements before installation.

Because ITFlow can hold client data and encrypted credentials, the backup guide calls for tested nightly backups and separate secure storage of the master encryption key. Test restoration of the files and database as one compatible set before relying on the system operationally.

Scheduled activities and email-to-ticket behavior require cron and mail setup. Stripe payments and private or external AI connectors are separately configured services; check their terms and data handling before enabling them for customer records.

Back to sections

Look a little closer

Before you choose

Pilot one fictional client from setup to support: add a device and service, submit a ticket, assign it, note the work, resolve it and test the portal view. That exposes whether asset links, notifications and close/reopen behavior match the MSP's process.

Check the exact release before promising optional SLAs, and verify scheduled tasks and mail alerts. A target shown on a ticket is not the same as an operational warning unless the required jobs are running.

Treat deployment and client-data recovery as part of the choice: keep a supported install path, maintain tested backups and preserve the encryption key. Add Stripe or AI only after the core service workflow and customer permissions are understood.

Back to sections

10 distinct sources behind this profile. Research observed Oct 20, 2026. Features and offers can change.
View sources and research →

Help keep this profile useful

Spotted an outdated detail? Send the correction with a supporting source. A verified account is needed to submit.

Suggest a correction ↗