Business Systems & ERP

Salesforce implementation and integration

Salesforce is a highly configurable CRM platform, which is both its strength and its risk. We implement it around your sales and service processes, keep customization to what you can maintain, and connect it reliably to the ERP, finance and other systems your organization depends on.

Who this service is for

A good fit if

  • You have licensed Salesforce, or are evaluating it, and need it implemented for your processes.
  • Your org has grown complex, with unused fields, overlapping automation and reports nobody trusts.
  • You still run older Workflow Rules or Process Builder automation and need it moved to Flow.
  • Sales, service and finance need Salesforce to agree with your ERP on customers, orders and invoices.
  • You need a security and sharing model that reflects regions, business units or confidential accounts.
  • Your internal admin needs help with larger changes, releases or integrations.

Another approach may suit you better if

  • You are a small team with a simple sales process. A lighter CRM such as HubSpot may cost less to run.
  • You want Salesforce rebuilt so heavily that standard features are replaced. Upgrades and maintenance become expensive.
  • You specifically require a Salesforce consulting partner. We are not one.

What this service is

We implement, improve and integrate Salesforce. Salesforce can model almost any process, which is why it suits organizations with complex sales, service or partner relationships. The same flexibility means an org can quickly fill with custom fields, overlapping automation and reports that disagree. Our aim is a Salesforce org your people trust and your admin can maintain.

We work on new implementations, migrations from other CRMs, and existing orgs that need restructuring. If you are moving data from another CRM or ERP, our article on CRM and ERP data migration readiness explains the preparation that makes a migration go smoothly.

What we work on

  • Sales: leads, accounts, contacts, opportunities, products and price books, quotes, forecasting and territory or team structures.
  • Service: cases, queues, assignment and escalation rules, entitlements, knowledge and service consoles.
  • Automation: Flow for approvals, routing, notifications and record updates, including migration of older Workflow Rules and Process Builder automation, which Salesforce has retired in favour of Flow.
  • Security and sharing: role hierarchies, permission sets, sharing rules and field-level security designed around who needs to see what.
  • Reporting: reports and dashboards built on agreed definitions, and connections to data analytics and BI tools when you need analysis across systems.
  • Portals: Experience Cloud sites for customers or partners, where in scope.

Integration with ERP and other systems

Salesforce usually needs to exchange customers, products, orders, invoices and payment status with an ERP or finance system, and often with marketing, e-commerce and a data warehouse. We choose between native connectors, an integration platform and direct API integration based on your volumes, editions and internal skills, and we apply the same principles as our system integration work: one owner per type of data, shared identifiers, retries, alerts and reconciliation. Salesforce API access and limits depend on your edition, so we confirm them before committing to a design.

Privacy and data in Canada

Salesforce often holds personal information about customers and contacts. Configuration should support your obligations under PIPEDA, applicable provincial privacy laws such as Quebec's Law 25, and CASL where Salesforce is used for commercial electronic messages. We design field-level security, retention practices and consent tracking with those obligations in mind. This is general information, not legal advice.

Working with your internal admin

Many organizations have a Salesforce administrator who knows the business well but lacks time for larger projects, integrations or a major clean-up. We work alongside that person rather than around them: they join design decisions, review changes in the sandbox and receive a proper handover, so their knowledge of the org grows rather than shrinks. We can also help set up a simple release process, with change requests, sandbox testing and release notes, so future changes do not reintroduce the problems a clean-up removed.

Licensing and independence

Promatics is not a Salesforce partner or reseller. You license Salesforce and any AppExchange products directly from their vendors, and we advise on editions and add-ons so you pay only for what you need. If a different CRM, such as HubSpot, would serve you better, we will say so.

What is included

The exact list is agreed in writing for each project. These are the usual deliverables and the usual boundaries.

Typical deliverables

  • Discovery of your sales, service and related processes, and a solution design for objects, record types and page layouts.
  • A security model covering roles, profiles, permission sets and sharing rules.
  • Configuration of standard and custom objects, fields, validation rules, list views and Lightning pages.
  • Automation built in Flow, with Apex or Lightning Web Components only where declarative tools cannot meet the need.
  • Data migration with de-duplication, test loads in a sandbox and reconciled record counts.
  • Integrations with your ERP, finance, marketing, website or data warehouse.
  • Reports and dashboards agreed with the people who use them.
  • A sandbox and release process so changes are tested before they reach production.
  • Role-based training, an admin guide and handover to your internal admin.

Not included unless agreed separately

  • Salesforce licences and add-on products, which you buy directly from Salesforce.
  • Third-party AppExchange products and their subscriptions.
  • Legal advice on privacy or marketing consent obligations.
  • Ongoing administration after handover, unless agreed in writing.

What we will need from you

Most delays in this kind of work come from access and decisions, not from the technical build. Knowing these early keeps the project predictable.

  • System administrator access to your org and at least one sandbox.
  • Process owners who can make design decisions for each team.
  • Exports from existing systems and a decision on which historical data to migrate.
  • Confirmation of your Salesforce editions and licences, since features and API access depend on them.
  • Your internal admin or IT contact, if you have one, involved from the start.
Delivery

How the work is delivered

Each stage ends with something you can review before the next one starts.

  1. Discover or assess

    For a new implementation, map processes and requirements. For an existing org, review configuration, automation, data quality and technical debt.

    Output: Requirements or org health report.

  2. Design

    Define the data model, security and sharing, automation approach, integrations and which system owns each type of data.

    Output: Solution design.

  3. Build and migrate

    Configure in a sandbox, build automation and integrations, and run test data loads until counts and key fields reconcile.

    Output: Tested configuration and migration scripts.

  4. Test and release

    Run user acceptance testing with realistic scenarios, then deploy to production through a controlled release.

    Output: UAT sign-off and release notes.

  5. Train and hand over

    Train each team on its own processes, support users after go-live and hand over documentation to your admin.

    Output: Training, admin guide and handover.

Testing and handover

  • Changes are built and tested in a sandbox before production.
  • Test data loads reconcile record counts and key fields before the final migration.
  • Security is tested with real user roles, not only as an administrator.
  • Automation has error handling, and failures notify a named owner.
  • Integration failures are logged, retried and visible.
  • An admin guide documents the data model, automation, integrations and release process.

What affects the cost

We do not publish package prices. Each estimate is based on an agreed scope, in Canadian dollars, with taxes shown separately. These are the things that move the number most:

  • The number of clouds, business units, record types and custom objects.
  • The complexity of the security and sharing model.
  • Whether requirements can be met declaratively or need custom code.
  • The volume and quality of data to migrate.
  • The number and complexity of integrations.
  • The number of users and teams to train.

Questions buyers usually ask

Are you a Salesforce partner?

No. We are an independent implementer. You license Salesforce directly from Salesforce, the org is yours, and we work in it with the access you grant.

Can you clean up an org someone else built?

Yes. We start with a health check of configuration, automation, data and security, then agree a prioritized plan. Clean-up is done in a sandbox first so teams are not disrupted.

Do you write custom code?

When it is the right tool. We prefer Flow and standard configuration because more people can maintain them, and use Apex or Lightning Web Components where the requirement genuinely needs code, with tests and documentation.

Can Salesforce connect to our ERP?

Usually, through a connector, an integration platform or the Salesforce APIs. What is available depends on your editions and the ERP, so we confirm limits and data ownership during design.

Where is our Salesforce data stored?

That depends on your contract and the infrastructure Salesforce runs your org on. Salesforce offers data residency options in some regions; we can help you ask the right questions so your privacy lead can assess the answer.

Planning a Salesforce project or clean-up?

Tell us whether you are implementing, migrating or improving an existing org, and which systems it must connect to. We will reply to arrange a conversation.