Skip to main content
FromNine
Menu

Enterprise platform · Salesforce

Salesforce, from the first enquiry to the closed case.

We set up and extend Service, Sales and Experience Cloud, give Agentforce reliable data to work from, and connect Salesforce with the ERP and other back-office systems. Staff serving customers, agents or partners see each case in full and resolve it from one screen.

For insurers, banks, healthcare groups and exporters in Malaysia that serve customers, agents and partners from one platform.

  • SalesforceSummit PartnerPartner status · Salesforce
  • ISO/IEC 27001 certified
  • 600+ European government projects
A single Salesforce org and its surrounding systems. In the middle is a single Salesforce org built on a shared data model. Around it are three layers: Data 360 for unified data, Experience Cloud for portals, and Sales and Service Cloud for employees. Six links run outwards: to Agentforce, to MuleSoft and APIs, to the back office in SAP or Odoo, to identity, to the data platform and to government services.

When Salesforce is the right choice, and when it is not

A good fit when

  • Many staff handle contact with customers, policyholders, partners or the public and need a single shared view of every case.
  • Customers, agents or partners need portals built on the data your staff already work with.
  • Processes change frequently, and administrators should be able to adjust them without commissioning development work for every change.
  • Licence, permit, inspection or grant applications follow case workflows with defined stages.
  • You want AI agents to act on CRM records within a platform that already provides governance.

Look elsewhere when

  • What you mainly need is finance, stock or production. That is ERP work, and Salesforce would at most sit in front of it.

    Alternative: SAP
  • A smaller business wants CRM, invoicing and inventory together at a modest cost. Odoo handles more of that on one database.

    Alternative: Odoo
  • A very large group of occasional users needs one simple workflow, and per-user licences would drive up spending. Building a custom application may be cheaper over its life.

    Alternative: Enterprise Software & SaaS

Our Salesforce work

Five types of work, normally combined. They also serve as column headings in the capability matrix further down.

  1. 01

    Implement

    Service, Sales and Experience Cloud

    Lightning pages, flows, a data model and a sharing model fitted to how your teams work, with Experience Cloud portals for customers, agents or partners.

    Deliverables

    • Solution design
    • Configured releases
    • Sharing model
  2. 02

    Extend

    Custom development

    Where configuration is not enough: Flow, Apex and Lightning Web Components, packaged and tracked in source control, covered by tests and released through an automated pipeline.

    Deliverables

    • Packaged extensions
    • Release pipeline
  3. 03

    Integrate

    Integration and events

    Salesforce linked to the ERP, the data platform and government services, using MuleSoft or the integration platform you already run, with Change Data Capture and platform events.

    Deliverables

    • Integration contracts
    • Event model
  4. 04

    Migrate

    Consolidation and clean-up

    Leaving older CRM systems behind, merging orgs, and moving retired Process Builder and Workflow Rules automation to Flow.

    Deliverables

    • Migration plan
    • Automation inventory
    • Reconciliation reports
  5. 05

    Operate

    Managed evolution

    We manage each of the three yearly Salesforce releases, watch limits and automation, and keep an improvement backlog that stops the org from growing complicated.

    Deliverables

    • Release calendar
    • Health checks
    • Improvement backlog

Capability matrix

Product areas we cover and the kinds of work we take on in each, shown row by row.

  • Sales Cloud

    Leads, opportunities, forecasts and selling through partners or agents.

    • Implement
    • Extend
    • Integrate
    • Migrate
    • Operate
  • Service Cloud

    Cases, omni-channel routing, knowledge articles and field service.

    • Implement
    • Extend
    • Integrate
    • Migrate
    • Operate
  • Experience Cloud

    Accessible portals for customers, agents, partners and members of the public.

    • Implement
    • Extend
    • Integrate
    • Operate
  • Public sector solutions

    Case handling for licences, permits, inspections and grants.

    • Implement
    • Extend
    • Integrate
    • Operate
  • Data 360

    Unified profiles and content that feed segmentation, analytics and the grounding of AI answers.

    • Implement
    • Integrate
    • Operate
  • Agentforce

    Agents limited to defined topics and actions, with guardrails and testing before release.

    • Implement
    • Extend
    • Operate
  • MuleSoft and APIs

    Change Data Capture, platform events and an API-led integration approach.

    • Implement
    • Integrate
    • Migrate
    • Operate
  • Org strategy and DevOps

    One org or several, development from source control, packaging and release management.

    • Extend
    • Migrate
    • Operate
  • Security and Shield

    The sharing model, Event Monitoring, Shield Platform Encryption and the choice of hosting region.

    • Implement
    • Operate

AI on Salesforce

Built into the platform

Agentforce is the Salesforce platform for AI agents. Each agent works inside the topics and actions your administrators set, uses CRM data to choose what to do next and can pass the conversation to a member of staff. Every call to a language model passes the Einstein Trust Layer, which masks sensitive data, writes an audit log and relies on zero-retention terms agreed between Salesforce and its model providers.

Grounding comes from Data 360 (formerly Data Cloud), which brings together customer data, documents and other unstructured content, plus retrieval that prompts and agents can call on. Because features, consumption prices and regional availability shift from release to release, we verify each one against your editions and contract.

Built alongside the platform

An agent sometimes needs to reach beyond Salesforce, into SAP documents, a records management system or a rules engine. In that case it may be better to build the agent as a separate service outside the platform. Users still reach it inside Salesforce, as an action or through an API, so their screens do not change.

Whichever route you take, agents get narrow permissions, approval points and full logging. We test them against scenarios agreed with you before go-live and keep testing in production, and uncertain cases go to a member of staff.

Choosing the route

  1. 01

    Will the work take place mainly in Salesforce screens, using Salesforce data?

    If yes

    Start with Agentforce, drawing on Data 360, with the Trust Layer in control.

    If no

    Consider a separate agent outside the platform that users call as an action.

  2. 02

    Does the agent need to update records held in other systems?

    If yes

    Route those updates via MuleSoft or APIs, each one approved and logged.

    If no

    Keep it inside Salesforce and give it read-only access to external data.

  3. 03

    Can you predict the consumption cost at your volumes?

    If yes

    Go ahead, and track consumption once it is live.

    If no

    Pilot it with realistic volumes and weigh the cost against building it yourself.

Towards a Salesforce org that stays manageable

  1. Step 01

    Discover

    Processes, user groups, data sources and any existing orgs, plus a check of editions and licences.

    • Process map
    • Org assessment
  2. Step 02

    Design

    The data and sharing models, the interface contracts, and an org strategy built to last.

    • Solution design
    • Integration contracts
  3. Step 03

    Build in increments

    Configuration before code; every change is versioned and passes through an automated test pipeline.

    • Working releases
    • Automated tests
  4. Step 04

    Migrate and connect

    Data moved and reconciled, and live interfaces running to the ERP and to the data platform.

    • Reconciliation reports
    • Monitored interfaces
  5. Step 05

    Launch

    Training, a phased roll-out and close support alongside the teams who use the org.

    • Adoption plan
    • Hypercare log
  6. Step 06

    Evolve

    Release management comes first; automation and agents follow when data quality allows.

    • Release calendar
    • Improvement backlog
Illustrative example

Agency and customer service at a life insurer

01Situation
A life insurer could be serving policyholders and its agency force from an ageing CRM, with consent records kept in separate files and policy data in the core insurance system.
02What we would deliver
Service Cloud with one case model for policyholder and agent requests, an Experience Cloud portal for agents, an Agentforce agent that prepares draft answers from vetted knowledge articles, and consent and notice records in the same data model, so every contact shows what the policyholder agreed to under the PDPA.
03Decisions that stay with people
The agent only drafts and suggests. Service staff sign off any reply that promises a payout, sets a deadline or changes a policy, only staff may alter a consent record, and each step the agent takes is logged.
04How results would be tracked
Time to first reply, share of requests closed without a handover, how often staff edit agent drafts, and completeness of consent records per policyholder.

Salesforce among your other systems

Salesforce keeps the customer relationship; orders, invoices, stock and the legal record usually belong to other systems. We connect it with SAP or Odoo, with the data platform and with government services, using MuleSoft or your current integration platform. Change Data Capture and platform events keep everything in step, so overnight batch jobs no longer spring surprises.

High data volumes call for designs that respect governor limits from the outset: the bulk APIs, processing that runs asynchronously, and synchronising only what is needed instead of every record. Our integration specialists own the contracts on both sides.

Illustrative example

People and channels

  • Employees in Salesforce
  • Customer and agent portals
  • Contact centre channels

Salesforce

MuleSoft · platform events · CDC

Systems and data

  • Back office in SAP or Odoo
  • Data platform
  • Identity provider
  • Government and register services
How Salesforce connects to the systems it serves
Read the diagram as text

On the left are people and channels: employees working in Salesforce, portals for customers, agents and the public, and contact centre channels.

Salesforce sits in the middle and reaches the other systems through one integration layer: MuleSoft, Change Data Capture and platform events.

To the right sit systems and data: the identity provider, the data platform, the back office in SAP or Odoo, and services for government and official registers.

Salesforce by sector

Licence, permit, inspection and grant cases on the Salesforce public sector solutions, portals on Experience Cloud, sign-in through MyDigital ID where an agency uses it, and screens designed to be accessible from the start.

600+

European government projects

  • Financial Services

    Customer onboarding, everyday servicing and complaint handling for banks, insurers and takaful operators. Every step leaves an audit trail, Shield encrypts sensitive fields and agents stay within set permissions, designed with the Risk Management in Technology (RMiT) policy document of Bank Negara Malaysia (BNM) in view.

  • Healthcare & Life Sciences

    For private hospital groups and clinics: patient enquiries, referrals and portals for partner doctors, with tight sharing rules because health data is sensitive personal data under the PDPA.

  • Manufacturing & Industry

    For exporters selling through partners in Europe: distributor portals, field service and warranty cases tied to the orders and inventory held in the ERP.

Malaysia

Salesforce and Malaysian personal data rules

Customer records, cases and portal accounts in a Salesforce org are personal data under the Personal Data Protection Act 2010 (Act 709). Since 1 June 2025, a data controller appoints a data protection officer (DPO) where the Commissioner’s thresholds are met, and notifies the Personal Data Protection Commissioner of a personal data breach as soon as practicable, which the Commissioner’s guidance sets at 72 hours. Consent, and the notice given in the national and English languages, must be traceable for each customer.

Where the same org also serves customers in the EU, the EU General Data Protection Regulation (GDPR) can apply under its Article 3(2), consumer portals fall under the European Accessibility Act, and an agent that helps decide matters affecting individuals must meet the EU AI Act’s documentation and oversight duties for its risk level.

We build the sharing model, consent records and retention rules for both from discovery onwards, so adding a market means configuring, not starting over.

Common questions about Salesforce

Is Agentforce mature enough for what we need?

Often, when the work is a contained service or sales task on tidy CRM data: replying from knowledge articles, summarising a case, or updating records under firm rules. It is a weaker fit when the task depends on information or decisions that live outside Salesforce.

Our first step is a brief review of data quality, access rights and likely volumes. One agent is then built, checked against scenarios you sign off and measured, and only after that does its remit widen.

One org or several: which suits us?

A single org keeps data and processes in one place and makes integration simpler. More than one org can be justified by legal separation, very different business models or rules on where data must be hosted. We compare those reasons with the effort of keeping several orgs synchronised, and write the decision down so it outlasts the next restructuring.

How do Salesforce and SAP stay aligned?

The starting point is an agreement on ownership: which system is the master for which data. After that, events and APIs connect the two rather than copies. Customers and quotations typically originate in Salesforce, SAP is the master for orders and invoices, and status updates flow back. Our SAP team follows the same interface contracts.

Where will our Salesforce data be stored?

Salesforce hosts orgs on Hyperforce in a number of regions, with an Operating Zone in the EU for qualifying services. Which data remains in a region depends on your products and add-ons, AI features among them. We trace every data flow, show where data is stored and processed, and write the hosting location agreed with you into the contract. Any transfer of personal data out of Malaysia must meet section 129 of the PDPA, as amended by Act A1727 with effect from 1 April 2025.

Our org carries years of old automation. What comes first?

An inventory. Salesforce no longer supports Workflow Rules and Process Builder, so that automation has to move to Flow, but converting it one to one often repeats old mistakes. We bring automation together per object, retire anything unused and put tests in place, which makes the org easier to change rather than merely newer.

Can public services be built on Salesforce?

Yes. Permit, licence and grant processes work well as Salesforce cases, with portals, sign-in through digital identity and links to official registers. That experience comes from Europe: 600+ government projects for public authorities in EU Member States, some completed and others still running. For a Malaysian agency or statutory body, it means procurement documentation, accessibility and audit trails prepared from the outset. Our public sector page has more detail.

Let us look at your Salesforce org together

Whether you are building a new org, cleaning up an existing one or introducing Agentforce, the first step is a discussion of your processes, your data and your users.