Salesforce Integration in New Zealand

The line between clicking and coding

Salesforce is unusual among business systems in how much it can do without a developer. Flows, validation rules, custom fields, page layouts, approval processes and reports are all administrator work. They cost a fraction of custom code, they can be changed by someone in your own team, and they survive Salesforce's three annual releases with far less attention.

Apex — Salesforce's programming language — and Lightning components are the other side of the line. They are the right answer when:

• The logic genuinely cannot be expressed in configuration.
• You are talking to a system outside Salesforce.
• Volume is high enough that configuration becomes slow.
• You need a user experience the standard interface will not give you.

Every line of Apex is an asset you now own and maintain. That is fine when it buys you something; it is expensive when it exists because writing code was easier for the consultant than learning your process.

Ask each firm quoting to mark which parts of their proposal are configuration and which are code, and to justify the code. The ones who have done this a long time will have already made that split themselves.

Integration is where most of the value is

Salesforce is rarely the problem. The problem is that Salesforce does not know what the accounting system knows, and your ERP does not know what the sales team promised.

The usual New Zealand shapes:

• Salesforce to accounting. Opportunities become invoices in Xero or MYOB; payments come back so salespeople can see who has paid.
• Salesforce to ERP or inventory. Stock availability and pricing visible while quoting, orders flowing the other way.
• Website to Salesforce. Enquiries, signups and support requests arriving as real records rather than emails.
• Your product to Salesforce. Usage and account health visible to the people selling and renewing.

Build these in a layer of their own rather than scattering the logic through Apex triggers. It is slightly more work at the start and it is the difference between a system a new administrator can understand and one only its author can.

Three releases a year, whether you are ready or not

Salesforce updates itself three times annually and does not ask permission. Configuration nearly always survives. Well-written Apex with proper test coverage usually survives. Undocumented customisations and integrations that depend on undocumented behaviour are the ones that break.

Two questions worth asking every developer:

• What test coverage will the code have, and can I see it?
• Is release testing included in support, or billed each time?

Salesforce requires 75 percent test coverage before code can be deployed to production, so tests are not optional — but "meets the minimum" and "actually tests the logic" are different things, and only one of them helps you in March.

Licences are not in the quote

Whatever a developer quotes you, Salesforce licensing sits on top and is paid separately, per user, per year. This catches people out in two specific ways:

• A build that assumes everyone who touches it has a full licence, when the fifty warehouse staff who need read access do not need one.
• A portal for customers or partners, where Experience Cloud licensing has its own model and can dominate the total cost.

Ask each firm to state the licences their proposal requires, separately from their own fee. A good consultant will design around licensing deliberately, because it is often the largest number on the page.

Ask who will actually do the work

Salesforce is deep enough that experience is worth real money. Someone who has integrated it with an ERP has met the problems that appear in month three; someone who has read the documentation has not.

The useful questions:

• Who specifically will do this work, and what have they built like it?
• Can I speak to a client with a similar shape of project?
• What is handed over at the end — documentation, admin training, access to the repository?
• Can our own administrator maintain what you build, or does every change come back to you?

That last question matters more than any technical answer. A build only its author can change is a subscription you did not agree to.

Comparing five quotes

Prices will vary widely because the approaches will. Read for:

• Who separated configuration from code, and justified the code?
• Who priced Salesforce licences separately and honestly?
• Who described how integrations fail and recover?
• Who included handover, documentation and admin training?
• Who told you a part of your request did not need building at all?

Describe what Salesforce needs to know that it does not know today, which systems hold that information, and who has to see it. The firms who work with Salesforce daily will tell you quickly which half of your list is an afternoon of configuration and which half is a project.