HubSpot + IFS Cloud integration

IFS builds software for businesses that manufacture, service and manage complex assets, so an IFS customer tends to sell something that lasts: the equipment, the service around it and the parts it consumes over the years. IFS Cloud holds that history. The commercial team working in HubSpot sees the relationship but not the installed base, the open orders or the invoices behind it.

That gap costs renewals and follow-on sales. A salesperson walks into a meeting without knowing that the last order shipped late or that an invoice is in dispute. Marketing cannot reach the owners of a product line that is due for replacement, because the product line and its owners live in IFS.

There is a decision to make before any mapping. IFS Cloud has sales records of its own, business leads among them, so part of the pipeline may already live inside the ERP. Settling which system owns leads and opportunities comes first. After that the split is simple: IFS supplies the customer, the order, the invoice and the part, and HubSpot supplies the pipeline and the activity. IFS also ships named releases, such as 25R2 and 26R1, and the integration has to survive each one.

A first IFS build maps five objects. Each IFS customer lands as a HubSpot company, with its contacts beside it. Each customer order becomes a deal, each customer invoice a custom object record, and each sales part a product. Business leads stay out of a first build until ownership of the pipeline is settled.

Direction is one way into HubSpot at first, with IFS as the system of record for everything commercial it holds. Plan any write back as its own phase, usually a won deal that should become a customer order, and IFS makes a stale write safe: an update through a projection carries the record’s ETag in an If-Match header, so an edit based on an old copy fails instead of overwriting newer data.

Keys are IFS’s own: the customer ID, the order number, the invoice ID and the sales part number, each held in a custom HubSpot property. Contacts match on email, with the IFS contact ID as the tie breaker.

IFS pushes a signal and our service pulls the record, with a sweep behind both. For each object we configure a custom event in Solution Manager on the entity’s table, firing on new, updated and removed rows, and attach a REST Call event action that posts to our ingest endpoint through IFS Connect’s REST sender with a bearer token.

The event is a signal rather than the record. The consumer takes the key from it, reads the full record from the projection with an OAuth 2.0 client credentials token, and upserts into HubSpot keyed on the IFS ID, followed by a separate association pass.

A scheduled sweep pages each entity set with $top and $skip and compares it with what HubSpot holds, so a change that raised no event is still caught. IFS documents no general changed-since filter across entity sets, so the sweep compares full pages rather than asking for recent rows. Our service runs outside IFS, which is how IFS expects outside extensions to run, while the event configuration travels as an application configuration package from the CFG environment to UAT and PROD.

On IFS the route follows two things: which API covers each of your objects, and who is allowed to configure events. IFS asks integrators to prefer Premium APIs, then integration projections, then standard projections or entity services, and a custom API integration can follow that order object by object.

IFS’s own documentation names Dell Boomi as an example of middleware that splits a structured message into the atomic calls its standard APIs expect. Where Boomi already runs, it is a reasonable home for the IFS side, though it still needs a reconciliation step of its own.

Commercient’s IFS app is the packaged route: a third-party sync for a standard feed, with the mapping and the support owned by Commercient.

1. Scope. We settle who owns leads and opportunities, list the objects, and find the API class that covers each one in API Explorer.
2. Architect. We fix the keys, the custom events and their attributes, the REST Call actions, the IAM client and the sweep schedule.
3. Build. The service is built against a CFG or UAT environment with a HubSpot sandbox and a portal allowlist, and the events ship as a configuration package.
4. Validate. We fire each event type on purpose, run a full sweep, and reconcile counts with the order desk.
5. Operate. We watch event volume against sweep repairs, rerun the regression suite at each Early Access, and keep replay available.