“Don’t touch it,” you say to your team.
You’re referring to your 20-year old CRM running on PostgreSQL.
It works, but it’s old, so it’s not a system you want to go digging around in or mess with.
If you were to build on top of that CRM, it would be a huge undertaking and who knows what technical debt you’d incur by doing so.
Not really an option.
At some point you eventually want to move the data off of that older CRM, but that’s for later.
The task in front of you is that you need to build a support ticketing system AND you need the data in that CRM.
And it needs to be done FAST.
What’s the best way to handle this scenario:
- Without tying yourself down to some external platform that will lock you into their ecosystem
- Withing getting charged you more as you scale or,
- Without having to build it from scratch
- And without incurring a bunch of technical debt or added complexity to an old system
What you need is something flexible, which is what a REST API layer is.
A system that lets you create the core forms without starting from scratch AND be able to handle data supplements.
What do I mean?
Building A Data Supplement System
The goal is to build a new system, on the side, as a supplement to your 20 year old PostgreSQL-based CRM.
The central piece of a ticketing system will likely be a long-ish form that collects a number of pieces of data to create the support ticket.
You build that with drag and drop forms in Form.io before you finish your coffee. Done.
Now, a significant portion of the data that needs to populate the fields isn’t going to come from the user. It’s going to come from the CRM database.
Since everything in Form.io has an API, you can configure the form to pull all the relevant data from the CRM when the logged-in user creates a new ticket (new form).
This of course is easy because Form.io forms are client-rendered, which I talked about here.
And by the way, you can configure Form.io to authenticate against your existing users database—no need to create a new one.
Then whatever fields are left, the data supplements, the user completes and hits submit and the support ticket is built.
Where does that ticket live?
In Form.io, not the CRM.
Because no one’s touching that CRM.
Then, whenever you need to pull some data, such as show me all the tickets from this customer, it’s one API call to load those tickets. Form.io is acting like a RESTful database in this scenario.
A working prototype could be setup in a matter of days (or perhaps even less).
Think of Form.io as a thin, REST API layer that you put on top of your existing systems and that lets you introduce new features and capabilities with speed. That’s what I mean when I say rapid deployment.
And if you decide to ALT-F4-scrap the project rm -r /ticketingsystem/*
, your CRM remains intact, just as it was before you started.