Skip to main content
FromNine
Menu

Salesforce practice

Salesforce, from first enquiry to closed service request.

Our teams set up and extend Sales Cloud, Service Cloud and Experience Cloud, base Agentforce on data you can trust, and link Salesforce to SAP, Odoo and your back office. Service teams and relationship managers see each request in full, and consent is recorded in the form the DPDP Rules require from May 2027.

For banks, insurers, NBFCs and B2B companies in India that serve customers, dealers and partners from one platform.

  • SalesforceSummit PartnerPartner status · Salesforce
  • ISO/IEC 27001 certified
  • 600+ European government projects
A single Salesforce org and its connections. A single Salesforce org with one shared data model sits in the middle, surrounded by three layers: Sales Cloud and Service Cloud used by staff, Experience Cloud for customer and dealer portals, and Data 360 holding harmonised data. Six links lead outward from the org: Agentforce, MuleSoft and APIs, the SAP or Odoo ERP, identity, the data platform, and government APIs such as API Setu and DigiLocker where a service uses them.

When Salesforce fits, and when another choice is better

A good fit when

  • Large teams handle customer, policyholder, dealer or partner interactions and need one shared view of every request.
  • Customers or dealers need portals that work on the same records as your staff.
  • Your service processes change every quarter, and you want administrators, not developers, to make most of those changes.
  • Onboarding, complaints and claims follow staged workflows with a named owner at each step.
  • You plan to let AI agents act on CRM records, within a platform that already enforces roles and logging.

Look elsewhere when

  • The pressing need is the ledger, stock or production planning. An ERP should carry that, and Salesforce may sit in front of it later.

    Alternative: SAP
  • An MSME wants leads, GST invoices and inventory in one low-cost system. Odoo handles more of that on one database.

    Alternative: Odoo
  • Thousands of occasional users, such as field agents or channel partners, need one simple screen, and per-user licences would outweigh everything else. A custom application can cost less over its life.

    Alternative: Enterprise Software & SaaS

Five types of Salesforce work

Most engagements combine several of these five. They also serve as the column headings in the capability matrix.

  1. 01

    Implement

    Core clouds and portals

    We shape the data and sharing models, flows and Lightning pages to the way your teams work, and build Experience Cloud portals for customers, dealers and partners, with consent captured at sign-up.

    Deliverables

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

    Extend

    Custom development

    Where configuration reaches its limit, we write Apex, Lightning Web Components and Flow, packaged from source control, covered by tests and released through an automated pipeline.

    Deliverables

    • Packaged extensions
    • Release pipeline
  3. 03

    Integrate

    Interfaces and events

    Events, Change Data Capture and MuleSoft, or the integration platform you already run, tie Salesforce to SAP or Odoo, the data platform and government APIs.

    Deliverables

    • Integration contracts
    • Event model
  4. 04

    Migrate

    Consolidation and clean-up

    Migration from an older CRM, merging of orgs, and the move from retired Workflow Rules and Process Builder automation to Flow.

    Deliverables

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

    Operate

    Run and improve

    We manage the three Salesforce releases each year, watch limits and automation, and keep a backlog that stops the org from becoming complex as it grows.

    Deliverables

    • Release calendar
    • Health checks
    • Improvement backlog

Capability matrix

The Salesforce areas we cover and the type of work in each. Read each row across.

  • Sales Cloud

    Leads, opportunities, forecasts and channel or partner sales.

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

    Service requests, omni-channel routing, knowledge articles and field service.

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

    Portals for customers, dealers and partners, with accessible front ends that meet WCAG 2.1 level AA.

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

    Licences, permits, inspections and scheme applications handled as cases.

    • Implement
    • Extend
    • Integrate
    • Operate
  • Data 360

    Unified profiles and content for segmentation, analytics and grounding AI, with consent attached to each profile.

    • Implement
    • Integrate
    • Operate
  • Agentforce

    Agents limited to agreed topics and actions, with guardrails, and tested against scenarios before go-live.

    • Implement
    • Extend
    • Operate
  • MuleSoft and APIs

    API-led integration, platform events and Change Data Capture towards SAP, Odoo and other back-office systems.

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

    One org or several, source-driven development, packaging and release pipelines.

    • Extend
    • Migrate
    • Operate
  • Security and Shield

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

    • Implement
    • Operate

Salesforce and AI

Standard on the platform

With Agentforce, Salesforce lets you build AI agents that stay inside topics and actions your administrators configure. An agent uses CRM records to decide what to do next and hands over to a staff member when needed. Every model call passes the Einstein Trust Layer. It masks sensitive data, writes an audit log and relies on zero-retention terms with Salesforce’s model providers.

Grounding comes from Data 360, the product formerly called Data Cloud, which brings customer records, documents and retrieval together for prompts and agents. Salesforce changes features, consumption prices and regional availability with each release, so we verify them for your editions and contract, and for the locations where your data may be processed.

Built beside the platform

Some tasks need records Salesforce does not hold: SAP documents, a loan origination system at an NBFC, or a rules engine. There a service built outside Salesforce often works better. We surface it in Salesforce through an action or an API call, which keeps staff in familiar screens.

Whichever route you take, an agent has narrow permissions, a maker-checker step before it changes money or commitments, and a complete log that also supports CERT-In’s six-hour incident reporting. Scenario tests run before go-live and continue in production; when an agent is unsure, a person takes over.

Choosing the route

  1. 01

    Do the records and screens involved belong mostly to Salesforce?

    If yes

    Agentforce is the starting point, using Data 360 for grounding and the Trust Layer for control.

    If no

    Consider an agent built outside Salesforce that staff call as an action.

  2. 02

    Must the agent update records held in SAP, Odoo or another system?

    If yes

    Each such update goes via MuleSoft or an API, with maker-checker approval and a log entry.

    If no

    Leave it in Salesforce and give it read-only sight of outside data.

  3. 03

    Can you forecast consumption charges at your transaction volumes?

    If yes

    Go ahead, and track consumption once in production.

    If no

    Run a pilot at real volumes first and weigh its cost against a custom build.

Towards a Salesforce org that stays manageable

  1. Step 01

    Discover

    Map processes, user groups and data sources, assess any existing org, and check which editions and licences you hold.

    • Process map
    • Org assessment
  2. Step 02

    Design

    Agree the data and sharing models, the consent and purpose fields the DPDP Act calls for, the integration contracts and a durable org strategy.

    • Solution design
    • Integration contracts
  3. Step 03

    Build in increments

    Configure first and code only where configuration ends; each change is versioned and passes an automated pipeline.

    • Working releases
    • Automated tests
  4. Step 04

    Migrate and connect

    Move data with reconciliation reports and bring up live interfaces to SAP or Odoo and the data platform.

    • Reconciliation reports
    • Monitored interfaces
  5. Step 05

    Go live

    Training by role, rollout in phases and hypercare with your service teams.

    • Adoption plan
    • Hypercare log
  6. Step 06

    Evolve

    Releases on a fixed calendar; agents and automation come once the data supports them.

    • Release calendar
    • Improvement backlog
Illustrative example

Service and consent for a general insurer

01Situation
A general insurer handles policy servicing, claim queries and complaints through a contact centre, branch staff and its website, with customer data split between an old CRM, the policy administration system and spreadsheets. DPDP duties for Data Fiduciaries apply from May 2027.
02What we would put in place
Service Cloud with one case model for policy, claim and complaint requests, an Experience Cloud self-service portal that records consent and its withdrawal, an Agentforce agent that drafts replies from approved knowledge, and MuleSoft links to the policy and claims systems.
03Where an officer decides
The agent only prepares drafts. A staff member signs off any reply that promises a payment, sets a date or alters cover, and the agent’s actions are logged one by one.
04How success would be measured
Time to first response, share of requests resolved by the first team, grievances closed inside the ninety-day period, and the edit rate on agent drafts.

Salesforce among your other systems

The customer relationship lives in Salesforce, while orders, GST invoices, stock and the legal record sit in SAP or Odoo. MuleSoft or the integration platform you already run links them, along with the data platform and any government API a service relies on. Change Data Capture and platform events keep each side current, so nobody waits for an overnight job.

High volumes, such as policy or loan records, are designed around governor limits from the first sprint: Bulk API loads, asynchronous jobs and selective sync rather than full copies. The Integrations & APIs team is responsible for the interface contracts in both directions.

Illustrative example

People and channels

  • Staff in Salesforce
  • Customer and dealer portals
  • Contact centre channels

Salesforce

MuleSoft · platform events · CDC

Systems and data

  • SAP or Odoo ERP
  • Data platform
  • Identity provider
  • Government APIs
How Salesforce connects to people and systems
Read the diagram as text

Left: people and channels, with staff working in Salesforce, portals for customers and dealers, and contact centre channels.

Centre: Salesforce, linked to every other system through a single integration layer of MuleSoft, platform events and Change Data Capture.

Right: systems and data, with SAP or Odoo as the ERP, the data platform, the identity provider, and government APIs.

Salesforce by sector

Licences, permits, inspections and scheme applications on Salesforce’s public sector solutions, with portals on Experience Cloud, Aadhaar-based authentication and DigiLocker document fetch where a department uses them, and accessibility to GIGW 3.0 designed into each screen.

600+

European government projects

  • Banking & Financial Services

    Onboarding, service requests and complaint handling for banks, NBFCs and insurers, with audit trails, Shield encryption, DPDP consent records and agents held within defined permissions.

  • Healthcare & Life Sciences

    Patient service, referrals and partner portals for hospital groups and diagnostic chains, with strict sharing rules for health data under the DPDP Act.

  • Manufacturing & Industry

    Dealer portals, field service and after-sales requests for auto component and equipment makers, connected to orders and stock in the ERP.

India

Salesforce and Indian data protection

A Salesforce org that holds personal data of customers in India falls under the Digital Personal Data Protection Act, 2023 (DPDP Act). Consent must be free, specific, informed, unconditional and unambiguous (section 6(1)), so consent records and their withdrawal belong in the data model, not in a spreadsheet. Under the DPDP Rules, 2025, Consent Managers register with the Data Protection Board of India from November 2026.

From May 2027 the Rules add itemised notices, security safeguards with logs kept for at least one year, breach intimation to the Board with a detailed report within 72 hours, and answers to grievances within ninety days. Each of these lands in Service Cloud and in the portals.

For orgs that also serve customers in the EU, the GDPR applies to that processing, consumer portals must meet the European Accessibility Act, and an agent that helps decide about people needs the records and human oversight the EU AI Act requires for its risk class. We design for both sets of rules from discovery, so a new market becomes configuration work rather than a fresh project.

Questions about Salesforce

Is Agentforce ready for what we want to do?

For narrow service and sales tasks on clean CRM records, usually yes: replying from approved articles, summarising a service request, or updating fields under clear rules. It is weaker when the decision needs information that lives outside Salesforce.

Our first step is a short check of data quality, access rights and likely volumes. After that we build a single agent, test it on scenarios your team agrees, and extend its scope only once the measurements support it.

One org or several: what is right for us?

One org is easier to integrate and keeps processes and data in one place. Separate orgs can make sense when Indian and European entities must be kept apart legally, when business models differ sharply, or when data must stay in a particular region. We set those reasons against the ongoing cost of synchronising orgs, and write the decision down so it holds after the next restructuring.

How do Salesforce and SAP stay consistent?

Ownership comes first: each record type gets one owning system. Accounts and quotations normally begin in Salesforce, sales orders and GST invoices are SAP’s, and order status is published back to Salesforce as events. Our SAP practice shares the interface contracts with the Salesforce team.

Where will our Salesforce data be stored and processed?

Salesforce operates on Hyperforce, with regions in the EU among others and an EU Operating Zone for eligible services. Which data stays in a region depends on the products and add-ons you license, AI features included. For personal data of people in India, the DPDP Act permits transfer outside India unless the Central Government restricts a country by notification (section 16(1)), and a sectoral law with stricter conditions takes precedence (section 16(2)). Before you choose, we trace each data flow and record where data is stored and processed, so that it can be written into the contract.

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

A full inventory comes first. Salesforce has ended support for Workflow Rules and Process Builder, so they must be replaced with Flow, yet converting them one to one tends to preserve their flaws. We merge the automation on each object into a few tested flows and retire whatever is no longer used, which leaves an org that is simpler to change.

Do you have public-sector experience on Salesforce?

In Europe, yes: permit, grant and benefit services run as cases, with portals for citizens, digital identity and connections to base registries. Across 600+ projects for European public administrations, completed and ongoing, we learned the procurement and accessibility discipline such services need. For a State department or an urban local body in India, the comparable building blocks would be Aadhaar-based authentication, DigiLocker and GIGW 3.0. See Government & public sector.

Tell us about your Salesforce org

A new org, an inherited one or a first Agentforce agent: describe your service processes, data and users, and we will propose where to begin.