Gestor nexo and Sfera: the CRM integration where writing matters more than reading

The Integration That Is Already Half Done

Every guide in this series has started in the same place: a program, an API, a connection you do not have yet. Gestor nexo starts somewhere else, and it takes people a moment to believe it.

If a client runs Gestor nexo next to Subiekt nexo, the CRM is not a second system standing beside the ERP with a gap to bridge. InsERT says it plainly: the two work on wspólnych kartotek klientów i asortymentu, cenników i promocji — shared client and product records, shared price lists and promotions. Offers in Gestor convert into Subiekt's commercial and warehouse documents. One podmiot. The contractor you read through Sfera for Subiekt is the same row the sales rep has open in the CRM.

So when someone asks what it costs to integrate their CRM as well, the honest answer is that a good chunk of the work is already behind you. Connection model, assembly references, the .NET Framework constraint, the service account, version discipline — all of it carries across from the Subiekt side unchanged, and I wrote it up there instead of repeating it here.

Then comes the part that does not carry across. It is not technical.

The Licence Is Per Program, Not Per Installation

Sfera in the nexo line is a capability of the PRO tier. I made that point in the Subiekt guide and thought I was done with it. I was not. There is a second half that only shows up once a second program enters the room.

Subiekt nexo PRO gives you Sfera for Subiekt. It does not give you Sfera for Gestor. Sfera dla Gestora belongs to Gestor nexo PRO, listed there next to advanced custom fields, custom dictionaries, flags, reports, extension points and custom automatic actions. InsERT's own Sfera PRO+ materials list the programs separately for exactly this reason — Subiekt, Gestor, Rewizor, Rachmistrz, Gratyfikant — and price per workstation.

Now picture the common case, because it really is common. A distributor bought Subiekt nexo PRO two years ago because an integrator needed Sfera for a webshop. Sales asked for a CRM later, nobody had a reason to pay for a PRO tier on it, and Gestor went in as standard. Today that company keeps the CRM data you want in the same database you already have a connection to — and has no licensed way for your code to touch it.

The failure mode deserves naming, because it is not an error message. Your integration will not crash. Someone on the team will find the Gestor tables through the connection they already have, write a query, and it will work. The data really is right there. The bill arrives months later: an upgrade that moves the tables, a licence conversation nobody planned for, a support call InsERT has no obligation to take. Same mistake as the read-only SQL replica I warned about on the enova365 side, and more tempting here than anywhere else, because the shared database makes it feel legitimate.

Ask for the tier of every program in the podmiot, by name, in the first conversation. Not "do you have nexo PRO". Which programs, which tier, how many workstations. The answer changes who needs to be in the room, and finding out before the estimate costs less than finding out after it.

Why Read-Only Is Almost Worthless Here

Now the part that genuinely surprised me on my first one of these.

In every other post in this cluster I argue for the same first build: start read-only. Pull stock, contractors, prices, settlement balances. Earn the right to write later. That is right for an ERP, because the first write touches money, stock or tax — and because a read-only integration pays off immediately, the data being locked inside a system most of the business cannot see into.

A CRM inverts both halves. Read-only delivers close to nothing: the client list is the least secret data in the company and everyone who needs it already has it on screen. And the write you actually want is the cheapest one in the whole InsERT object model.

A działanie — an activity; in Gestor's vocabulary a task, meeting, phone call, letter or note — changes no money, no stock, no tax position, no document state. It records that something happened, with a date, a client and a person attached. If an agent creates a wrong one, a human reads it and deletes it. Total cost of the error: fifteen seconds of mild irritation.

Hold that against the permission ladder I set out earlier: read, propose, write, send or sign, with the real boundary between three and four. The ladder still holds. What Gestor shows is that it is not one ladder for a whole company. Level three in the CRM is safer than level two in the ledger. Ranking permissions by verb is a shortcut. Rank them by what a mistake costs to undo, and a lot of automation arguments get much shorter.

The Mailbox Is the Asset

Gestor carries a built-in mail client over IMAP, so customer correspondence lives inside the podmiot, next to the offers, the activities and the client cards.

If you are building an agent, that is the most valuable data in the whole InsERT estate, for one reason: it is the only place where the why is written down. The ERP knows a customer ordered eighty cartons on Tuesday. The mail thread knows they asked whether Thursday delivery was possible, that a rep promised it, and that the last three conversations were about a damaged pallet nobody has credited yet. No document carries any of that. Every useful thing a sales-side agent does — drafting a follow-up, spotting a quote that went quiet, preparing a call briefing, noticing a customer has asked the same question three times — comes out of the correspondence, not the ledger.

Two cautions. Both cheap early, expensive late.

Settle the data questions before you design. This is a mail store inside an ERP database, holding personal data about people who are not your client's employees. Retention, who may read it, what happens on export, what happens when a rep leaves. Ask once, in writing, at the start. You are not after a legal opinion. You are after a named person who owns the answer.

Expect it to be the biggest thing in the database. Mail with attachments outgrows document tables comfortably, and that growth is what produces the ceilings I wrote about on the Optima side — a database never sized for the volume, meeting a limit nobody was watching. Ask how large the podmiot is today and how fast it grew over the last year. One question. It has saved me from two bad estimates.

The Offer Is the Seam

Everything soft about a CRM stops at one object.

Gestor's offers convert into Subiekt documents, several offers inside a single proces ofertowy included. That conversion is the moment the CRM stops describing the world and starts changing it — prices, quantities, commitments. Which makes it the one CRM object where the agent boundary snaps back to ERP rules: propose, never confirm, with a named person taking the decision.

The line I use with clients is short enough to survive a meeting: an agent may describe what happened as often as it likes, and may never be the last party to decide what something costs. Activities, notes, briefings, tidied client cards, draft follow-ups — unattended. Anything convertible into an invoice — proposed, reviewed, confirmed by a person.

It also tells you where to spend your effort. Convertible objects are a small minority of what a CRM does all day. The enormous, unglamorous majority — remembering, writing things down, connecting a conversation to a record — is exactly the half machines are good at and people are bad at.

Check What You Already Own First

Before you write any Sfera code, look at what the PRO tier already gives the client. A fair share of CRM automation requests do not need a programmer at all.

Gestor nexo PRO ships własne automatyczne akcje and własne definicje zestawów dynamicznych klientów — custom automatic actions, and custom definitions of dynamic client sets that keep themselves current as the data changes. Between them they cover a good deal of what people mean by "we want the system to remind us". Add zaawansowane pola własne wraz ze słownikami własnymi and the structured field you were about to build in code may turn out to be a configuration screen.

Two reasons to check. The obvious one: nobody should pay a developer for a feature they have already licensed. The less obvious one, and the reason I do this every time: what the client has already configured tells you what they will actually use. An office running three automatic actions with maintained dynamic client groups is ready for an agent. An office where none of it was ever switched on has a habit problem, not a software problem, and a Sfera integration will land exactly where the unused features landed.

If you build custom fields anyway, everything I learned the hard way about custom fields as an undocumented schema change applies here unchanged. Different names, identical trap.

What I Would Build First

One number before any code: the activity coverage rate — what share of last quarter's real customer interactions exist in Gestor as a działanie.

Count the activity records for a month, then ask the sales team how many customer conversations they think they actually had. The gap is always large, and always the same shape. Meetings get logged; the forty emails around each meeting do not. Which is odd, because with Gestor's mail client those emails are already in the database — present as messages, absent as structure. Nothing needs collecting. Something needs turning into a record.

So the first build is that, and only that. Read the correspondence, propose a działanie per meaningful exchange with the client and the date already filled in, write the ones a person accepts. A level-three write on the cheapest object in the system, something visible in the first week, and the measurement comes built in: coverage rate before, coverage rate a month later.

Build it as a thin HTTP service on the Windows host holding the nexo installation, exactly as on the Subiekt side — one component that knows Sfera exists, everything else talking JSON to it. That shim is also why the Gestor work comes cheap once the Subiekt work is done, and why the comparison in the integrator's API guide is worth reading before you choose where to start.

Wondering whether a Gestor nexo integration is worth building, or whether the licence tiers kill it before it starts? Get in touch. An hour with your podmiot, your tiers and one month of real correspondence settles it faster than any feature list.