Connecting Applied Epic to Salesforce: The Real Story
Lessons learned from the field and helping our customers get Applied Epic and Salesforce talking effectively.
Why Agencies Want This Integration
If your agency or brokerage runs Applied Epic and you're thinking about bringing Salesforce into the mix, you might be overwhelmed with information on how you can achieve this. There are several paths, and they each come with advantages and disadvantages. Let's talk through it.
Most agencies and brokers we work with are in the same spot. The servicing team lives in Applied Epic and it handles policies, claims, renewals, and carrier submissions well. But the sales side needs more. Pipeline tracking, lead nurturing, marketing automation, cross-sell identification. That's where Salesforce comes in. The question is how you connect them.
Two Paths: The Connector vs. Custom Integration
There are really two approaches here. We've done both, and our position is clear: a custom integration is the better path for most agencies. But you should understand what each option actually involves before making that call.
Path 1: AESF Connector
- Pre-built field mappings between Epic and Salesforce objects
- Bidirectional sync for accounts, contacts, opportunities, policies, activities, and attachments
- Support for Business Accounts and Person Accounts
- Optional Financial Services Cloud (FSC) extension package
- Applied handles the middleware infrastructure
Path 2: Custom via Middleware
- Full control over data mapping, sync timing, and business logic
- No per-user connector licensing
- Integrate with other systems beyond just Epic and Salesforce
- Freedom to change the integration as your needs evolve
- Middleware such as MuleSoft or custom-built
What You Should Know About the Connector
Applied Systems offers a managed package called "Applied Epic for Salesforce." It's a full application that installs into your Salesforce org.
- Per-user licensing on top of your existing Salesforce and Epic licenses (more on the costs below)
- Sync triggers at lead conversion to opportunity. That's when data first pushes from Salesforce into Epic
- Lead conversion is overridden by the managed package. You'll need to use Applied's interface, not the standard Salesforce process
- Field sync directions are hard-coded: some fields are bidirectional, some only go one way, and some don't sync at all
- The BDE is a batch interface, not real-time. The underlying data exchange runs as a nightly batch process. Changes in one system may not appear in the other until the next day. This is one of the most common complaints we hear
- No control over error handling or validation. The managed package handles these internally, but you have no visibility into what failed or why
- Page layouts can be locked down as part of the managed package, limiting your ability to customize the user experience
- Customization is restricted. Because it's a managed package, changes to fields and layouts typically need to go through Applied's professional services team
- Not self-install. You need Applied's professional services team involved
- Renewals stay in Epic. They're still run through Applied Epic rather than Salesforce
- Ongoing support is on Applied's terms. If anything breaks or you want to add new fields or objects, you're going to have to wait for Applied Epic's support team
Not every user needs all three licenses. Your producers are focused on new business and should be working in Salesforce, not logging into Epic. Your account managers handle renewals and servicing in Epic. Structure your licenses around how people actually work and you'll avoid paying for seats nobody uses.
The connector has its place, but in our experience most agencies hit its limitations within the first year or two.
Why We Recommend Custom Integration
A custom integration using middleware such as MuleSoft or a purpose-built solution gives you what the connector doesn't: control. You decide what data syncs, when it syncs, how conflicts are resolved, and what happens when something fails. You can add fields, change logic, and extend the integration to other systems without waiting on Applied or paying for a package upgrade.
It's more work upfront. You own the middleware infrastructure and ongoing maintenance, and you need a partner who understands both the Epic API and Salesforce data model. But the trade-off is that you're building something that grows with your business instead of boxing you in.
Sync on your terms
Real-time, hourly, or scheduled. You control the frequency.
Built-in error handling
Logging, alerting, and visibility when something fails.
Full control over fields and objects
Add, change, or remove anything. No waiting on Applied.
Data flows when you say so
Trigger sync at whatever sales stage fits your process.
Access to more objects
Claims and other objects the connector doesn't include.
Experience Cloud portals
Build a custom portal for your insureds without managed package restrictions.
No per-user cost creep
Grow or acquire agencies without increasing connector fees.
Simpler licensing
Producers only need a Salesforce license, not three.
Plug in other systems
Add a benefits platform, another AMS, or any other integration.
You own the support
Your team or your partner maintains it. No waiting on Applied's queue.
How the Applied Epic API Actually Works
Applied Epic's API suite is organized into 28 REST APIs covering two categories: resource APIs that handle individual data objects and module APIs that bundle related operations together. For a Salesforce integration, these are the ones that matter most:
| API | What It Covers | Salesforce Relevance |
|---|---|---|
| CRM Module | Clients, contacts, employees, brokers, companies | Account and Contact sync. You'll spend most of your time here |
| Policy Module | Policies, lines, claims, statuses, rates | The real insurance data. Layered structure: policy header → lines → coverage details |
| Contacts API | Person and business contact records | Includes SSN, driver's license, government IDs for underwriting workflows |
| Clients API | Top-level client records, benefits, HIPAA details | Parent record connecting policies, claims, contacts, and attachments |
| Opportunities API | Sales pipeline: new and renewal business | Maps most directly to Salesforce Opportunities |
| Activity API | Interactions, tasks, and follow-ups across accounts, policies, and claims | Maps to Salesforce Activities (Tasks and Events). Critical for tracking producer and account manager touchpoints |
| Attachments API | Document management (create, read, update) | Maps to Salesforce Content Documents (not the deprecated Attachment object) |
Data Mapping: What to Think About With a Custom Integration
If you go the custom route, you control the mapping, but you also own the complexity.
- Account/Client mapping between Salesforce Accounts and Epic Client records is usually the foundation. Get this right first.
- Contact sync is straightforward conceptually but watch out for duplicate management across systems.
- Policy data has the most depth. Epic's policy structure (policy header → lines → coverage details) doesn't map 1:1 to Salesforce's Insurance Policy object. You'll need to make design decisions about what level of detail to sync.
- Opportunities map relatively cleanly but you need to decide: does an opportunity originate in Salesforce and push to Epic, or the other way around? For renewals, it's usually Epic → Salesforce. For new business, it's usually Salesforce → Epic.
- Attachments require a custom Lightning Web Component (LWC) to pull files from Applied Epic and display them in Salesforce. Files stay stored in Epic, so you're not eating into your Salesforce storage.
A custom LWC for Applied Epic files. This is something we've built for other agencies. A purpose-built component that pulls files from Applied Epic via the REST API and displays them directly on the relevant Salesforce record. A sortable table with columns for file name, date, and type. Users can download files to their computer, upload new attachments through Salesforce that get stored back in Applied Epic (saving your Salesforce storage), and hit a refresh button to reload the latest files. We recommend this approach for any custom integration.
Pricing
Agencies always ask "what does this cost?" It depends on which path you take.
Connector Costs
- $20,000 to $25,000Setup fee from Applied to install and configure the connector
- ~$50 / user / monthConnector license, on top of your existing Salesforce and Epic licenses
- ~$12,000Sandbox refresh fee to reconnect your test environments (commonly seen at this level)
If you have 20 people who need the integration, that's an extra $12,000 per year in connector fees alone. Over three to five years, it adds up fast.
Custom Integration Costs
The custom approach has higher upfront build costs but lower ongoing expenses. You're paying for middleware licensing and maintenance hours, but not per-user connector fees. And now your producers only need a Salesforce license.
- ~$1,500 / month each for the API and SDKApplied will often quote $3,000/month total for both. The SDK is the legacy format that everyone is trying to move away from, yet they'll still try to charge you for both. Negotiate hard on this one, especially if you're a new Applied Epic customer. API access is table stakes for any modern software application.
- Middleware: fixed annual costYour middleware platform has an annual fee, but it's based on throughput rather than per-user. As your team grows or you acquire new agencies, that cost stays predictable instead of scaling with every new seat.
For most agencies, the math favors custom once you factor in the long-term connector licensing, the sandbox refresh fees, and the cost of working around the connector's limitations. The upfront investment is higher, but you end up with something you actually own and can change.
Implementation: What to Expect
Connector Timeline
Plan for a minimum of 12 weeks:
- Purchase connector licenses from Applied
- Install the managed package into your Salesforce sandbox
- Applied turns on API access on their side
- Configure field mappings and sync settings (with Applied PS)
- Test the full cycle: lead creation, conversion, opportunity sync, Epic sync, and data flowing back
- Validate data accuracy, permissions, and user access
- Deploy to production
You'll need access to both a Salesforce sandbox and an Applied Epic test environment running simultaneously.
Custom Integration Timeline
Expect 3 to 5 months as this is a custom build to your specifications:
- API credential setup and authentication
- Data model mapping between systems
- Middleware development and configuration
- Sync logic (real-time vs. batch, conflict resolution)
- Error handling and monitoring
- Testing with production-like data volumes
- Phased rollout (usually accounts/contacts first, then policies, then activities)
Either way: Start with the most critical data. For most agencies that means accounts and contacts first, then opportunities, then policies, then activities and attachments. Don't try to sync everything on day one.
Talk to Us About Your Integration
We're a Salesforce partner that works exclusively with insurance companies. We've seen the Applied Epic integration from every angle: the connector path, the custom path, and the "we tried the connector and now want to switch" path.
Get a Straight Assessment