How to Build an Operating Model That Works with Spanish Insurance Law

Underwriting delays at an insurer rarely start with underwriting. They start earlier. A broker sends a submission with gaps in the exposure data. A referral rule lives in someone’s spreadsheet. Or the policy history is stuck in a core platform that the underwriter can’t query without help from IT. Salesforce Insurance Cloud can improve that operating model. It can’t make the decision for you about which system owns policy, rating, claims, and customer data.

For CIOs and enterprise application leaders at Spanish insurers, the real question isn’t whether the platform has insurance features. It’s whether its data model, workflow tools, integration patterns, and security controls fit the lines of business you actually write, and whether they fit the Spanish regulatory framework. A commercial insurer handling complex endorsements needs something different from a personal-lines insurer processing thousands of home and motor claims, or from a bancaseguros operator selling through a bank’s branch network. If you treat all of these as a standard CRM rollout, you end up paying for expensive workarounds.

Where Salesforce fits in a Spanish insurer’s architecture

Salesforce Insurance Cloud works best as the engagement and orchestration layer around your insurance operations. It gives teams one view of the household, account, intermediary, policy relationship, service history, and every interaction. Paired with Financial Services Cloud, it makes servicing customers and intermediaries far more manageable. That matters in a market like Spain, where agents, brokers, and bank channels often sit side by side.

The value is easiest to see in a concrete workflow, such as commercial underwriting intake. A broker submits a renewal package through Experience Cloud or an intake app. Salesforce validates the required fields, creates the submission record, and routes it by region, line of business, premium threshold, and appetite rule. The underwriter then sees prior interactions and open service issues in one place. OmniStudio can guide the intake and pull data from several systems, so users don’t have to jump between disconnected screens.

That cuts manual re-keying and gives operations leaders a cleaner measure of submission-to-quote cycle time. It doesn’t mean Salesforce should become your policy administration system. If your existing PAS handles issuance, billing, regulatory reporting, rating, and accounting correctly, replacing it just to consolidate screens is usually a poor investment.

The practical architecture is often:

• Salesforce for intermediary and customer engagement, work management, exception handling, and guided processes
• The PAS for the policy lifecycle and rating
• A claims platform for claim financials and adjudication
• An integration layer that exposes governed services between them

Where exactly the boundaries fall depends on how complex your products are and how good your current core systems are.

Salesforce Cloud needs a data ownership model

The hardest design decision isn’t configuration. It’s data ownership. Without clear ownership, policy details, insured-party records, and claim statuses get copied into Salesforce and slowly drift away from the systems that run the real transactions.

Start with the business objects that drive daily work. Salesforce might own the submission, broker interaction, task assignment, referral decision, and service case. The PAS might own policy number generation, coverage terms, premium calculation, policy status, and issuance. The claims platform might own reserve movements, payments, recoveries, and claim closure. Salesforce can display those values, but displaying a value and owning it are two different jobs.

This becomes critical at endorsements and renewals. Under the Ley 50/1980 de Contrato de Seguro (LCS), either party can oppose tacit renewal: the policyholder with at least one month’s notice and the insurer with two months’ notice before expiry (Article 22). Your renewal workflow has to track those dates reliably. That’s hard to do if renewal data lives in three places that disagree. In the same way, if a user changes a mailing address in Salesforce, does that update the PAS, the customer master, both, or neither until it’s verified? You need a documented event flow, error handling, and a reconciliation process. A nightly batch might be fine for marketing preferences. It isn’t fine when an underwriter needs current loss history before accepting a risk.

Salesforce Data Cloud can unify selected customer and interaction data for segmentation and service context. It isn’t a reason to copy every policy transaction into another store. Define the use case first: intermediary servicing, retention campaigns, complaints handling, or next-best-action support. Then bring in only the data you need, with retention and access rules you can defend to the regulator.

Design underwriting and claims work, not generic records

Insurance teams adopt a platform when it shortens a real decision or removes a real handoff. A generic opportunity pipeline does neither for an underwriter working through referrals, inspections, subjectivities, and capacity approvals.

For underwriting, model the submission as work that moves through clear states: received, triaged, pending information, quoted, referred, bound, declined, or withdrawn. Record why it moved, who decided, and which rule or authority level applied. In Spain, this connects directly to the policyholder’s duty of disclosure under Article 10 of the LCS. The insured answers the insurer’s risk questionnaire, so you need to keep exactly which questionnaire version was presented and what was answered. Limiting clauses also have to be highlighted and specifically accepted in writing (Article 3 LCS), so document generation and acceptance evidence belong in the workflow design. Don’t hide the approval matrix inside Flow logic if underwriting governance needs to review it. It needs an administrable structure, version control, effective dates, and an audit trail.

For claims, the design should mirror your operating model and Spain’s legal deadlines. The LCS asks the insured to report a claim within seven days (Article 16). It also requires the insurer to pay at least the minimum amount owed within 40 days of the claim (Article 18), and it applies penalty interest when payment is delayed beyond three months (Article 20). Your first notice of loss (FNOL) process should timestamp everything, track those SLAs automatically, and escalate before a deadline is missed. A typical setup creates the case in Salesforce Service Cloud, routes it by severity and coverage type, and hands it to the claims platform for adjudication. For extraordinary risks such as floods or storms, the workflow also needs a clear path to the Consorcio de Compensación de Seguros, which covers those events in Spain. Recent large-scale weather events have shown how quickly claim volumes can overwhelm a process that wasn’t designed for it.

Putting every claims function into Salesforce isn’t automatically better, especially when a specialist platform already handles complex claim financials well.

UX/UI work matters here because bad screens cost you operationally, not just visually. If a claims agent has to open six panels to check whether a claimant has a prior loss, handle times go up and so do avoidable transfers. A role-based console that puts coverage summary, contact history, required documents, and next action in one workspace can cut training time and improve data quality. Test that with task-completion and error-rate measures, not just stakeholder opinion.

Build Spanish and EU compliance into the workflow

Spanish insurers work under a dense, layered framework. The good news is that most of it maps cleanly onto Salesforce design decisions, as long as you plan for it from day one.

Supervision and governance. The Ley 20/2015 de ordenación, supervisión y solvencia (LOSSEAR), which transposes Solvency II, sets the governance, risk management, and outsourcing requirements that the Dirección General de Seguros y Fondos de Pensiones (DGSFP) supervises. If Salesforce supports critical or important functions, treat it as part of your outsourcing and governance framework, not as a standalone SaaS tool that marketing happened to buy.

Insurance distribution. The Real Decreto-ley 3/2020, which brought the EU Insurance Distribution Directive (IDD) into Spanish law, requires you to identify customer demands and needs, provide pre-contractual information, manage conflicts of interest, and keep product oversight and governance (POG) in place. For a CRM, that means the demands-and-needs assessment, the information delivered, and the target-market check should be captured as structured, auditable records, not as attachments nobody can report on.

Digital operational resilience. Since January 2025, the Digital Operational Resilience Act (DORA) applies to Spanish insurers. In practice, your Salesforce environment can’t be run as an isolated tenant. Identity architecture, privileged admin access, third-party connections, ICT incident classification and reporting, resilience testing, and change control all belong in your ICT risk framework. Salesforce and each connected vendor need to appear in your register of information on ICT third-party providers. An unmanaged integration user with broad API access is a DORA problem even if the user interface is perfectly permissioned.

Data protection. The GDPR and Spain’s Ley Orgánica 3/2018 de Protección de Datos (LOPDGDD), enforced by the Agencia Española de Protección de Datos (AEPD), shape how you process personal data. Health data from life, health, accident, or disability products is special-category data and needs a clear legal basis, strict minimum-necessary access, and strong logging. A service agent shouldn’t see medical information or sensitive claim notes just because the records belong to the same customer. Build role-based access, field-level security, controlled integration identities, and retention rules around real operating roles. Get the data model right before migration, because answering access or deletion requests is much harder after years of duplicated policy and interaction data have built up in custom objects, sandboxes, archives, and analytics.

Complaints handling. Spanish insurers must run a customer service department (servicio de atención al cliente) with formal response deadlines. Salesforce Service Cloud is a natural fit for tracking complaints, deadlines, and escalations, provided the case model reflects the regulatory categories and timelines.

AI has a narrow but valuable role in insurance operations

AI works when it supports a controlled process, not when it quietly decides outcomes that affect customers or carry regulatory weight. In Salesforce, Einstein capabilities or a governed Claude-based assistant can summarize long broker emails, flag missing submission documents, draft service responses, or retrieve approved underwriting guidance. These are high-friction tasks where a human still reviews the result.

Risk classification, claim denial recommendations, fraud scoring, and underwriting eligibility need a much higher standard. The EU AI Act classifies AI used for risk assessment and pricing in life and health insurance as high-risk. That brings requirements for risk management, data governance, human oversight, transparency, and post-market monitoring. Spain has also set up a dedicated AI supervisory agency (AESIA). Add GDPR’s rules on automated decision-making, and this stops being just a technical design discussion. You need explainability, documented validation, drift monitoring, clear escalation paths, and evidence that the model doesn’t produce unfair or discriminatory outcomes.

A sensible first release limits AI to retrieval and summarization over approved, permission-aware content. Measure whether it cuts document review time, improves submission completeness, or reduces service rework. Don’t call it a success because users generated more text.

Build the operating model before the backlog

A durable Salesforce Insurance Cloud program starts with a working session on one high-value flow, such as commercial renewal intake or FNOL. Map the handoffs, system-of-record decisions, exception paths, approval authorities, and the evidence you’d need for a DGSFP inspection or an internal audit. Then decide what belongs in standard configuration, what justifies OmniStudio or Flow, and what needs custom software because the workflow really sets you apart.

Us at Nuvolar, working with insurers and financial services companies across Spain and Europe, we treat these programs as enterprise workflow work, not screen replacement. The useful deliverable isn’t a huge feature backlog. It’s an operating design that shows which teams act, which data they trust, how exceptions get resolved, and which metric should move after go-live.

Start with the workflow that causes the most rework or delay. Make its controls visible, and give the people doing the work a faster route to a decision they can defend. That’s where Salesforce earns its place in a Spanish insurer’s architecture.