Salesforce Consultants near you

Salesforce organises its credentials by role, and lists them publicly along with maintenance requirements that holders must complete to keep a credential current as the product changes. A consultant's certifications are therefore checkable, and asking which ones they hold and when they were last maintained is a reasonable question rather than an impertinent one.

What a credential tells you is that somebody has studied a defined syllabus and passed an exam. It says nothing about whether they have built the thing you need, worked with an organisation your size, or can run a workshop with people who dislike change. A shelf of certifications on a proposal is a weak signal compared with two clients in your industry who will take a phone call.

For firms, look past the badges to the team you will actually get. Ask who specifically will be assigned, whether they are employees or subcontractors, whether any of the work will be delivered offshore, and who will still be there in month six. Partner status is awarded to the company; the people are what you are buying.

Serious Salesforce work does not happen in production. Changes are built in a sandbox, a separate copy of the org used for development and testing, and then deployed. Sandbox types differ in how much data and metadata they copy and how often they can be refreshed, and which types you have depends on your subscription, so confirm availability before the design assumes it.

Deployment moves metadata, meaning the configuration and code rather than the records. Teams do this either through the platform's own change set mechanism or, more commonly on larger projects, through source control and a deployment tool, which gives you a history of what changed and the ability to roll back.

Ask how your consultant intends to handle this before work starts. A partner who configures directly in production leaves you with no test environment, no change history and no safe way to try anything. It is faster in week one and expensive by month six.

The subscription agreement should be between Salesforce and your organisation, with billing in your name. Some partners resell, which can be legitimate, but understand what it means for renewal, for support escalation and for what happens if you change partner. Ask, in writing, how the subscription would be transferred to a direct relationship.

Keep at least two internal users with the system administrator profile and make sure at least one is not the person most likely to leave. Give consultants named user accounts with the access they need rather than a shared administrator login, and remove them when the engagement ends. Login history is only useful if each login belongs to a person.

Your data is yours, and the platform provides export tooling. Use it. Schedule a regular export outside Salesforce and verify it includes custom objects, attachments and the fields you would actually need to rebuild. Test the export by trying to read it, not by confirming the job ran.

The default should be configuration. Anything achievable with objects, fields, page layouts, validation rules and declarative automation is upgraded by the vendor, documented by the vendor and understood by any administrator you hire later. It is also the cheapest to change when the business changes.

The AppExchange is Salesforce's marketplace of installable packages. A managed package can save months of build for a well-understood need such as document generation or a specific integration, at the price of another subscription, another vendor relationship and another thing that must be compatible with each platform release. Check the vendor's support presence in Australian time zones before committing.

Custom code is right when nothing else will do, and wrong when it is chosen because it is faster for the developer. Code needs tests, a deployment path, documentation, and someone able to maintain it. Ask any consultant proposing code to explain what configuration option they ruled out and why.

Salesforce updates the platform on a seasonal cycle for every customer, whether or not you have a project running. Release notes are published in advance and a preview window is available before your org is updated, which is what the preview sandbox exists for.

Most releases pass without incident. The ones that do not tend to affect custom code, packages from the marketplace and anything relying on behaviour that was never formally supported. Build a short regression test script covering your critical paths, quoting, approvals, integrations, key reports, and run it in a preview sandbox before each release.

Budget a small amount of administrator time each cycle for this, and treat it as a standing commitment rather than an interruption. The organisations that get caught out are invariably the ones where nobody reads the release notes because nobody is responsible for reading them.