Integrations
Do you actually need an integration?
The question worth asking before calling in a developer.
The answer, nearly always, is no. The platform is used entirely from the screen, without writing a line of code. Integrating exists to stop typing the same thing twice, and that only pays off when that twice happens many times.
When you do NOT need it
- You are starting out. Integrating before you know how you will work is building on a process that will change.
- You handle few cases a month. Typing twenty onboardings costs less than maintaining an integration.
- What you want is documents in one place: for that, just use it.
When you do
| Signal | What to integrate |
|---|---|
| Someone copies the same data between systems daily | The API, to launch processes from your system |
| You often ask "have they signed yet?" to update something else | Automatic notifications |
| People work in a shared folder and will not give it up | Connected folder |
Important
Integrating costs technical time and has to be maintained when things change. It is a cost decision, not a requirement for using the platform: plenty of people never integrate and do fine.
Worth knowing
The practical rule: if you cannot name the specific person losing time today typing the same thing twice, it is not time to integrate.
›Can I start without integrating and do it later?
Yes, and that is recommended.
›Do I need an integration for third parties to sign?
No. They never need anything.
›Do I need a developer on staff?
To integrate, someone who can code. To use it, no.
A real case
The situation
A company delays starting for six months waiting to integrate with its ERP.
What you do
- Starts using it from the screen
- Integrates a year later, once it knows which processes are stable
What you get
Gains six months of use, and the integration it eventually builds is smaller than it would have been.
The situation
Integration is requested before the platform has been used on a real case.
What you do
- Works a few months without integrating and notes what gets typed twice
What you get
The integration is built on a measured problem rather than an assumed one.
The situation
A process that runs three times a year is put forward for integration.
What you do
- Counts the hours saved against the cost of maintaining it
What you get
Effort goes where there is genuine repetition.
The situation
What is actually needed is a monthly export of a list.
What you do
- Uses the export instead of an integration
What you get
The problem is solved with nothing to maintain.
The situation
IT says yes to everything without knowing the scope.
What you do
- Brings the specific flow and the fields needed
What you get
The conversation happens on something bounded.
The situation
It is integrated and six months later nobody uses the flow.
What you do
- Reviews which integrations have activity
What you get
What adds nothing gets switched off and what works stays.
This article answers
- do i need to integrate code contract with my system
- do i need a developer to use it
- can i use it without any coding
- when is an integration worth it