Passive Tracker to Active System

digibandit

Six months using ITFlow daily. 460 posts, 139 discussions started. Found the pattern:

ITFlow tracks, it doesn't act.

Features that collect data get built. Features that use that data to automate tasks don't. We (humans) are still the middlemen between ITFlow and itself.

Three Examples

Gmail failures: ITFlow sends emails. Gmail bounces them. The failures sit in our inbox waiting for manual checks. ITFlow knows it failed, we check manually anyway. @wrongecho and I working through this in Delivery incomplete/Address not found.

Billable assets: Client adds 3 workstations. They're in ITFlow, marked billable. Next invoice: manually type "13" instead of the system reading its own database. @kieran raised this in Link invoices/recurring invoices to assets.

Duplicate tickets: Customer replies. Email client sends Message-ID header. We manually merge tickets even though the headers already connect them. Auto merge tickets with the same subject has 8 replies pointing at this.

The system knows. We do the work anyway.

What Got Built vs What Didn't

May submission: 15 features requested. October: dark mode shipped, basic inventory shipped, OAuth2 shipped. Custom fields, parts-to-ticket binding, calendar sync, labor log editing, automatic invoice line items didn't.

The pattern is clear. Internal features get built. Data-acting features don't.

The Real Ask

100+ scattered requests in this forum. Same underlying need: let ITFlow act on the data it already tracks.

Some of this belongs in core (invoice calculations, ticket threading). Some works better as integrations (n8n automation, specialized inventory systems). That's for @johnny and @wrongecho to sort out based on what the community actually needs.

Here's what I need from you:

List one manual task you're doing that ITFlow already has the data for. Don't worry about how to solve it, just identify the gap.

Once we hit 20-30 solid examples, we consolidate the pattern and @wrongecho and @johnny take it from there.

My Examples

Manually checking Gmail for ITFlow bounce notifications
Typing asset quantities into invoices when system knows the count
Reconciling retainer hours in spreadsheets when system logs all time entries
Merging duplicate tickets when email headers already link them
Can't edit time entries after creation even though the data exists

Drop yours below.

kieran

Absolutely love this!!

However……The issue I see, is I imagine we all do things a little differently, and storing data is far easier than deciding which automation is the "right" one for a given scenario.

What I would like to see if possible is more emphasis on the development and documentation of the API and ideally a way of triggering webhooks.

This would allow automation platforms like N8N to do the heavy lifting of individual organisations needs and they can be custom to the individual requirements.

I'm working on a python wrapper for the API for a project I'm already working on, which I will open source and share once it is in a semi-usable state.

It would be great to have someone working on an N8N module for ITFlow, I had a brief look at this (asked ChatGPT) but it's not an area i have any experience in.

Just my two pence worth of ideas :-)

Whichever direction it takes ITFlow is an amazing bit of software and an incredible effort from @johnny and @wrongecho

digibandit

kieran Agreed, n8n (or whatever automation thingy you like best) will most likely be the way.

What are you missing (there abouts) for the API/documentation?

kieran

digibandit I put a post up previously. The client API only allows create and read. Doesn't allow update or delete. The php files appear to be missing, but I'm unsure if this is by accident or design.

I've not dug deeply into all of the API paths yet, mainly looking at client and contact at the moment. The documentation often only lists the basic read API. I know in any Open Source project it's a difficult balance with adding / updating features and adding documentation. I'd be happy to add some once I feel I have a better understanding of all of the API routes and the data they need / return.

digibandit

kieran Using itflow-org/itflowtree/master/api/v1 as the example for API stuff for the rest of this post.

We should try to aim for full CRUD

CRUD refers to the fundamental operations performed on data within an application or system. These operations are:

C: reate: Adding new data (e.g., creating a new user, a new product).
R: ead: Retrieving existing data (e.g., fetching a user's profile, listing all products).
U: pdate: Modifying existing data (e.g., changing a user's email, updating product details).
D: elete: Removing data (e.g., deleting a user account, removing a product).

Based on this criteria here is where we are as far as API is concerned:

Full CRUD (2 endpoints):

assets - create.php, read.php, update.php, delete.php
contacts - create.php, read.php, update.php, delete.php

CRU only - Missing Delete (2 endpoints):

credentials - create.php, read.php, update.php
documents - create.php, read.php, update.php

CR only - Missing Update & Delete (2 endpoints):

locations - create.php, read.php
clients - create.php, read.php

Special case (1 endpoint):

tickets - create.php, read.php, resolve.php (has resolve instead of standard update/delete)

Read only (11 endpoints):

software - read.php
payments - read.php
networks - read.php
domains - read.php
certificates - read.php
vendors - read.php
quotes - read.php
products - read.php
invoices - read.php
expenses - read.php
custom - readme.php

Priority should probably be completing CRUD for the endpoints that already have partial write capabilities (credentials, documents, locations, clients) before expanding to the read-only endpoints.