How I built a BPM / SOP system inside of Infinity

Hey guys.

I have a bunch of recurring SOPs for my team that should be triggered again and again when stuff happens in my business.

Think…

  • Onboard client
  • Onboard team member
  • Order inventory
  • Client check-in
    etc…

There are numerous systems out there and to be honest something like Tallyfy checks all my boxes. But it’s also $30/month per user (and I already have Infinity).

Also… the less systems you have, the simpler the systems. And if my team only have to log into one system (instead of one) they also have a better experience.

So I decided to try and build it in Infinity.

My requirements was that…

  • “External stuff” should be able to trigger a workflow. Like someone paying for one of our programs should result in an onboarding workflow to trigger.

  • Multiple tasks in a workflow should be able to be delegated to multiple people on my team.

  • Have workflow inputs. If you want to onboard a client. It’s a pretty good idea to know WHICH client we need to onboard, right? So we need to be able to send parameters (or inputs) to the workflow.

  • The workflow - when run - should result in some tasks for my team.

Right now the main thing that I want in the system (but haven’t implemented) is the ability to give some kind of “order” that the workflow tasks need to be done in (like… do this first… then this second).

But this is some pretty standard stuff that I can always built out in Infinity. For now we use “due dates” and priorities, then it’s up to my team to make their own decisions.

I shot what was supposed to be a short video here (if you’re interested in how I built it).

(it got a bit longer than planned… :see_no_evil:)

3 Likes

We have created a template, with cards for each notification along with the text, attachements, links to external articles showing why we are informing Clients what we are doing etc.

As each project has essentially the same start & statutory obligations (architecutre/construction/building) we have tick lists on the cards & also a NOT APPLICABLE attribute.

We then move any cards not applicable to that category … have a folder called PREVIEW that we put the template cards not yet in play into, so we can just go through it once on project startup.

Then, we bring them out of PREVIEW into play at the applicable time, to minimise what the Client sees at any one time (ie, not overwhelm, or discuss prior to need … such as why discuss keys at building handover, when the foundations are not even done).

Bit like the PREVIEW folder, we also have a WIP (work in progress) one, and also an ARCHIVE folder.

Templates is probably the way you want to go … we just us a normal board & duplicate it as our template, as we started before defined templates were possible.

1 Like

I like that you use the “Task” field.

I had kind of forgotten about that. Are you using that?

From what I can gather, you’re duplicating the entire board per client? (or?)

If I just create “templates” with the internal tasks field, that could also work (and should probably be way simpler that what I have built - if I can get Zapier og Pabbly connect to “duplicate” the template and throw it into a work queue).

The only thing that might hold be back, is how we use tasks currently (I don’t really want to have tasks both defined as items… and inside items).

But using the Task field would certainly be much easier to implement :smile:

1 Like

Tasks and tasks within items … umm … sub-tasks.

Just create a task attribute called sub tasks … or even SUB TASKS L1 … meaning level one … or can call it T1 for tier one … how ever you want.

But essentially call it a different name … be sure to maybe factor in the sub task feature, so you dont want to get confused with that, as the sub task feature really is more tick list & assignable.

To have it as a card in its own right (can use card referencing back to the main task) think of an attribute name to call it (thats different to the attribute function type … like text, date etc) and you can call it what you want.

To us, anything that is more than just a quick check off, really needs to be a card on its own, as if any of the check list items are held up for any reason, it does happen even if you think fingers crossed it wont … so as standard, always work one way, the right way, factor in it may … so any task that has any complexity or likely delay etc, if its a card per part, then its easy to see what is left as well, its a card.

We have not used the task field yet … we mainly use text, lists & dates etc … so we take any chance of automation accidents out of it … we control the data manually (or by triggering automations that are programmed)

If you want access into our demo board so you can take a look around, let us know & can give you the public access link & password.

Its a little out of date, but all the functionality is there to give you an idea of what you can achieve.