Skip to main content
FromNine
Menu

Enterprise platform · Salesforce

Salesforce, from the first enquiry to the closed case.

Our consultants configure and extend Service, Sales and Experience Cloud, prepare the data Agentforce depends on, and connect Salesforce with the ERP and back-office applications behind it. Anyone who deals with clients sees the whole case on one screen and can take action from there.

For insurers, investment services firms, public entities and Maltese companies that serve clients and residents from a single platform.

  • SalesforceSummit PartnerPartner status · Salesforce
  • ISO/IEC 27001 certified
  • 600+ European government projects
One org at the centre of your client systems. Salesforce occupies the centre as one org on a common data model. Three rings enclose it: Sales and Service Cloud for internal teams, Experience Cloud for external portals, and Data 360 for data brought together from many sources. Six lines lead away from the org, one each to Agentforce, MuleSoft and APIs, an SAP or Odoo back office, identity, the data platform, and Government services such as Malta e-ID.

Is Salesforce the right platform for you?

A good fit when

  • A large team deals with clients, residents or partners and every person needs the same complete picture of each case.
  • Clients, residents or partners need self-service portals working off the same records as your staff.
  • Processes are adjusted often, and you would rather have administrators make those changes than open a development project every time.
  • Permits, licences, inspections, grants or benefits move through case-based stages that are clearly defined.
  • You want AI agents to work on client data inside a platform with proper governance.

Look at alternatives when

  • Your main need is accounting, stock or production. An ERP should handle that, and Salesforce, if used at all, only as the layer in front for clients.

    Alternative: SAP
  • A family business or smaller firm wants CRM, invoicing and stock in a single, affordable system. Odoo covers more of that on one database.

    Alternative: Odoo
  • A very large group of occasional users needs one straightforward workflow, and licences per user would drive the cost. A bespoke application can then cost less to own.

    Alternative: Enterprise Software & SaaS

Our Salesforce services

Our Salesforce work falls into five types, usually mixed. The capability matrix lower down uses the same five as its columns.

  1. 01

    Implement

    Service, Sales and Experience Cloud

    Data and sharing models, flows and Lightning pages built around the way your teams operate, with Experience Cloud portals for clients, residents or partners.

    Outputs

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

    Extend

    Custom development

    Apex, Lightning Web Components and Flow where configuration reaches its limits, delivered as packages tracked in source control, covered by tests and released through an automated pipeline.

    Outputs

    • Packaged extensions
    • Release pipeline
  3. 03

    Integrate

    Integration and events

    Connections from Salesforce to the ERP, the data platform and Government services, via MuleSoft or your current integration platform, using platform events and Change Data Capture.

    Outputs

    • Integration contracts
    • Event model
  4. 04

    Migrate

    Consolidation and clean-up

    Leaving a legacy CRM, combining orgs, and moving Workflow Rules and Process Builder automations to Flow, since Salesforce no longer supports the older tools.

    Outputs

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

    Operate

    Managed evolution

    Release management through the three Salesforce releases each year, monitoring of limits and automations, and a backlog that keeps the org simple while it grows.

    Outputs

    • Release calendar
    • Health checks
    • Improvement backlog

Capability matrix

The Salesforce products we work in and the type of work we do on each. Each row reads from left to right.

  • Sales Cloud

    Leads, opportunities, forecasting of sales and partner channels.

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

    Cases, routing across channels, knowledge articles and field service.

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

    Accessible portals for clients, residents and partners.

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

    Case handling for permits, licences, inspections, grants and benefits.

    • Implement
    • Extend
    • Integrate
    • Operate
  • Data 360

    Single client profiles and content that feed segmentation, analytics and AI grounding.

    • Implement
    • Integrate
    • Operate
  • Agentforce

    Agents limited to defined topics, actions and guardrails, and tested before go-live.

    • Implement
    • Extend
    • Operate
  • MuleSoft and APIs

    Connections led by APIs, with platform events and Change Data Capture.

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

    A single org or several, source-driven development, packaging and controlled releases.

    • Extend
    • Migrate
    • Operate
  • Security and Shield

    Sharing settings, Shield Platform Encryption, Event Monitoring and choices for EU data residency.

    • Implement
    • Operate

AI in Salesforce

Built into the platform

Salesforce builds its AI agents on Agentforce. Administrators decide which topics and actions an agent may handle; inside those limits it reads CRM data to pick its next step and can transfer the conversation to staff. Every call to a language model passes the Einstein Trust Layer, which masks data, writes an audit log and relies on zero-retention terms agreed with the model providers Salesforce uses.

Data 360 (previously called Data Cloud) provides the grounding: unified client data, unstructured content and retrieval for prompts and agents. Because features, usage-based pricing and availability per region shift with every release, we check them against your editions and your contract.

Built next to the platform

Certain agents have to reach beyond Salesforce, into SAP documents, a records management system or a rules engine, for example. A custom agent or service that runs outside Salesforce is then often the sounder design. Staff still meet it inside Salesforce, as an action or an API, so their screens do not change.

Whichever route you take, each agent has limited rights, approval steps and a complete log. We test it on scenarios agreed with you before go-live and continue testing in production, and any case it is unsure of goes to a person.

Choosing a route

  1. 01

    Do Salesforce data and Salesforce screens account for most of the work?

    If yes

    Agentforce is the place to start, fed by Data 360 and guarded by the Trust Layer.

    If no

    Think about a custom agent running outside Salesforce, which staff call as an action.

  2. 02

    Must the agent update data owned by another system?

    If yes

    Let it act only via MuleSoft or APIs, where every change is approved and logged.

    If no

    Leave it inside Salesforce, with outside data visible to it but not editable.

  3. 03

    Can you predict the usage cost at the volumes you expect?

    If yes

    Go ahead, and keep watching usage once it is live.

    If no

    Test it first with realistic volumes in a pilot and set that cost against a custom build.

Steps towards a Salesforce org that stays manageable

  1. Step 01

    Discover

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

    • Process map
    • Org assessment
  2. Step 02

    Design

    Data and sharing models, interface contracts, and an org strategy that will still hold several years from now.

    • Solution design
    • Integration contracts
  3. Step 03

    Build in increments

    Configuration before code, with each change kept in source control and tested through a pipeline.

    • Working releases
    • Automated tests
  4. Step 04

    Migrate and connect

    Records transferred and checked, with interfaces to the ERP and data platform running live.

    • Reconciliation reports
    • Monitored interfaces
  5. Step 05

    Launch

    Training, a roll-out in phases and close support alongside the teams that use it.

    • Adoption plan
    • Hypercare log
  6. Step 06

    Evolve

    Managed releases, followed by agents and automation once your data can support them.

    • Release calendar
    • Improvement backlog
Illustrative example

Client service for a Maltese insurer

01Starting point
An insurer licensed by the MFSA handles policyholder questions, claims updates and complaints by phone, email and through brokers, with client data split between an ageing CRM and the policy administration system.
02What we put in place
A single case model in Service Cloud, a policyholder portal on Experience Cloud for following requests, an Agentforce agent that writes draft replies from approved policy wording and knowledge articles, and MuleSoft connections to policy and payment data.
03Where people decide
The agent only drafts and proposes; a member of staff approves every reply that promises a payment, sets a deadline or alters cover. Each step the agent takes is logged for audit and complaints handling.
04How we judge success
Time until the first reply, the share of cases closed without being passed on, and how often staff change the drafts the agent prepares.

How Salesforce connects to your other systems

Salesforce holds the client relationship. Orders, invoices, stock and the official record normally sit in other systems, and we connect them: SAP or Odoo, the data platform and Government services, through MuleSoft or whichever integration platform you already run. Platform events and Change Data Capture keep the systems aligned during the day, so there are no surprises from a batch that ran overnight.

Where volumes are high we respect the platform limits from the first design: bulk APIs, asynchronous jobs and selective synchronisation in place of full copies. Our integrations and API team is responsible for the interface contracts on both sides.

Illustrative example

People and channels

  • Staff working in Salesforce
  • Client and resident portals
  • Contact centre

Salesforce

MuleSoft · platform events · CDC

Systems and data

  • Back office on SAP or Odoo
  • Data and analytics platform
  • Identity provider
  • Government and registry services
Salesforce among the systems that depend on it
Read the diagram as text

On the left are the people and channels: staff working in Salesforce, portals for clients and residents, and the contact centre channels.

At the centre sits Salesforce, and every connection runs through MuleSoft, platform events and Change Data Capture as one integration layer.

On the right are the systems and data: the back office on SAP or Odoo, the data platform, the identity provider, and Government and registry services such as Malta e-ID.

Salesforce for your sector

Government & Public Entities

Government & Public Entities

Permits, licences, inspections, grants and benefits for ministries, departments and public entities, built on the Salesforce public sector solutions, with Experience Cloud portals, Malta e-ID login, links to Government registers and accessibility built into every screen.

600+

European government projects

  • Financial Services

    For credit institutions, insurers and investment services firms licensed by the MFSA: client onboarding, servicing and complaints with a full audit trail, Shield encryption, and agents that never exceed the rights given to them.

  • Healthcare & Life Sciences

    Patient and member services, referrals and partner portals for private clinics and care providers, with tight sharing rules for sensitive data.

  • Manufacturing & Industry

    Portals for distributors, field service and after-sales cases, connected to the orders and stock that the plant’s ERP holds.

Malta

Salesforce in Malta

A Salesforce org used in Malta has to satisfy several sets of rules at the same time. Personal data in cases and portals is covered by the GDPR, supervised in Malta by the Information and Data Protection Commissioner (IDPC), and that shapes the sharing model, retention periods and where data is processed. For a credit institution, insurer or investment services firm, DORA adds ICT risk duties under the Malta Financial Services Authority (MFSA), including the documentation of third-party providers such as Salesforce.

Portals for consumers fall under the Accessibility Measures (European Accessibility Act) Regulations (S.L. 627.03), with the Commission for the Rights of Persons with Disability (CRPD) as market surveillance authority. Agents that support decisions about people need the records and human oversight the AI Act requires for their risk level; in Malta, the Malta Digital Innovation Authority (MDIA) is the lead market surveillance authority.

We take these into account from the first workshop, so a new process or entity later is a matter of configuration rather than a fresh project.

Questions about Salesforce

Can Agentforce handle our use case today?

Usually yes for clearly scoped service and sales tasks on well-kept client data, such as answering from a knowledge base, summarising a case or updating records under fixed rules. It is a weaker fit when the task relies on data or decisions held outside Salesforce.

Our first step is a short check of data quality, permissions and expected volumes. One agent is then built, tried on scenarios you have agreed and measured, and only after that does it take on more.

Do we need one org or more than one?

A single org keeps data and processes in one place and is easier to integrate. Separate orgs can make sense where entities must be kept legally apart, where business models differ sharply or where data has to stay in a particular region. For a Maltese company that is part of a European group, this question often comes up early. We set those reasons against the effort of keeping several orgs aligned, and record the decision so that it outlasts the next restructuring.

How are Salesforce and SAP kept in line?

Ownership comes first: for each kind of data we agree which system is the master, and only then do we connect the two, with events and APIs rather than duplicated tables. Clients and quotations tend to start in Salesforce, SAP is the master for orders and invoices, and status changes are passed back. Our SAP consultants use the same interface contracts.

Will our Salesforce data remain inside the EU?

Salesforce runs on Hyperforce, which has EU regions, and provides an EU Operating Zone for services that qualify. Which data stays in the region depends on the products and add-ons you use, AI features included. For an MFSA licence holder that has to document where data sits, we trace every data flow and show where it is stored and processed before you take the decision.

Our org is full of legacy automation. What comes first?

An inventory. Workflow Rules and Process Builder have lost support and need to move to Flow, yet a one-to-one conversion tends to carry old errors across. We bring the automation for each object together, take out what nobody uses and add tests, so the org becomes simpler to change and not only more recent.

Do you build services for Government and public entities on Salesforce?

We do: case-based services such as permits, grants and benefits, with portals for residents, Malta e-ID login and links to Government registers. With 600+ public-sector projects across the EU behind us, completed or still running, including in Malta, we know the procurement and accessibility rules that apply, from calls for tenders on ePPS to S.L. 418.03. More on our work in Government & Public Entities.

Your Salesforce org: where to begin

Whether you are starting from scratch, tidying up an existing org or bringing Agentforce into service, the first step is a conversation about your processes, your data and your users.