If you produce eDetailers for a global pharma brand, you have probably had this brief: one core story, one approved visual language, and a field force that uses three or four different CRM/CLM tools depending on the market. IREP in one region, Veeva in another, a Salesforce-based setup somewhere else, and Vmobile for China.
This guide explains what IREP eDetailer development involves, how it compares to building for other platforms, and how to structure one codebase that can be packaged for IREP, Veeva CRM, Vmobile and Salesforce without rebuilding the presentation for each one. It also covers multi-platform eDetailers Ranbanka Systems has delivered through a pharma agency partner. One example is a compliant eDetailer for Novartis China integrated with Vmobile, Veeva CRM and IREP.
Why multi-platform eDetailers are now the norm for global pharma brands
Global brands rarely launch in one market. The same core narrative (mechanism of action, efficacy, safety, dosing) rolls out across regions, and each region's field force may run on a different CRM or CLM stack. A rep in one country opens the presentation inside Veeva. A colleague elsewhere opens it in IREP or a Salesforce-based tool. In China, the team may be on Vmobile.
The obvious answer is to rebuild the eDetailer for each platform. In practice that creates three problems:
- Cost multiplies. Every rebuild repeats development, QA and packaging effort.
- Review cycles multiply. Each separate build can trigger its own medical, legal and regulatory (MLR) review. Every approved change then has to be re-applied and re-checked in each version.
- Versions drift. Over time, markets end up showing slightly different slides, claims or references. Brand and compliance teams want to avoid exactly that.
The better goal is one content source with a thin platform layer that handles packaging, navigation and tracking for each target. The rest of this article is built around that idea.
A note on accuracy: platform behaviour, packaging rules and APIs change between versions. Always confirm specifics against the current vendor documentation and the client's own CRM configuration before you build.
What IREP eDetailer development actually involves
At its core, an IREP eDetailer is the same kind of artefact as any modern CLM presentation: a set of HTML, CSS and JavaScript slides designed to run on a rep's tablet. The work splits into three layers.
1. The core build
- Touch-first slides. Reps use tablets, so swipe navigation, generous tap targets and responsive layouts are essential. Hover states and tiny links fail once a rep is presenting in a real call.
- Animations that perform. Charts that build, mechanism-of-action sequences and transitions must stay smooth on the devices reps actually carry, not just on a developer's desktop.
- Offline playback. Reps often present in hospitals and clinics with poor connectivity. Every font, image, video and script must be bundled locally, and nothing should depend on a live network call.
2. Platform-specific concerns
Each CLM platform has its own expectations about how a presentation is delivered:
- How the package is structured and zipped
- How individual slides and sequences (or presentations) are defined
- How a slide links to another slide or to a different sequence
- Which thumbnails and metadata the rep's library view requires
3. Engagement tracking
The commercial value of an eDetailer depends on the data it sends back. That means which slides were viewed, for how long, and which interactions occurred, such as quiz answers, calculator inputs or tapped references. That data needs to flow into the call record in the CRM so marketing and sales ops can report on it.
An IREP eDetailer build checklist
Don't rely on assumptions about any single platform version. Work through a checklist like this with your developer:
- Package structure: folder layout, entry file, zip conventions and any manifest or metadata files the platform expects.
- Navigation API: how slide-to-slide and cross-sequence links are triggered inside the platform.
- Tracking calls: which events are captured, what the payload looks like, and how they map to the CRM record.
- Thumbnails: required sizes and naming for each slide.
- Offline assets: every font, image and media file bundled locally, with no external CDN dependencies.
- Device testing: the actual tablet models and OS versions the field force uses, tested inside the real CRM app, not only in a browser.
Designing one codebase for Veeva CRM, IREP, Vmobile and Salesforce
The key architectural decision is to treat the platform as a plug-in, not as the foundation.
Separate content from platform
Split the project into two layers:
- Shared content layer: slides, styles, animations, images, references and copy. MLR reviews this layer, and brand teams care most about it.
- Platform adapter layer: navigation, tracking and packaging. This layer is small, technical and different for each target.
Abstract navigation and tracking
Slides should never call a platform API directly. They call common internal functions instead, for example a goToSlide() or trackEvent() helper defined once in your own codebase. Each platform adapter implements those functions using that platform's mechanism. Moving from IREP to Veeva, or adding Salesforce, then means writing or swapping an adapter rather than editing dozens of slides.
Generate packages from one source
A build pipeline, such as a task runner or bundler script, takes the shared source and produces a separate, correctly structured package for each target platform. One command produces all the outputs. Every market stays on the same approved content, and updates are repeatable.
Handle the differences that bite
Even with a clean architecture, some differences need explicit planning:
- Screen sizes and orientation: different markets may use different tablets. Design for the range, and decide early whether the presentation is landscape-only.
- Fonts and local assets: brand fonts must be embedded and licensed for offline use. Some platforms are also strict about file paths.
- Touch-event behaviour: swipe gestures in your slides can conflict with the host app's own gestures. Test this inside each container app.
- China deployments: projects for Chinese markets may run on Vmobile and can carry regional requirements around hosting, assets and approvals. Confirm these with the local team at the start so they don't surface at packaging time.
Plan localisation as variants, not forks
Languages and market-specific claims should be content variants driven by configuration or separate copy files. They should not be separate copies of the codebase, because a fork per market is how version drift starts.
Case study: Novartis China, an eDetailer integrated with Vmobile, Veeva CRM and IREP
Ranbanka Systems worked through pharma marketing agency Lebeyon to deliver a fully compliant eDetailer for Novartis China. It is an interactive, touch-optimised HTML presentation for field reps.
The eDetailer was integrated with Vmobile, Veeva CRM and IREP. That makes it a real-world instance of the brief this article addresses: an eDetailer that has to work with more than one platform used by field reps. The stated result: Veeva CRM · Vmobile · IREP · Compliant delivery.
The broader lesson for agencies is that compliance and multi-platform integration should be planned together from the start, not treated as separate phases. If the platform targets are known when the brief is written, you can align content review, packaging and tracking requirements early. The alternative is retrofitting a finished single-platform build for other systems later, which is usually harder.
Case study: Humalog (Eli Lilly), Veeva CLM, IREP and Salesforce integration
Ranbanka also worked through Lebeyon to build an interactive eDetailer for Eli Lilly's Humalog brand. It was developed in HTML, CSS and jQuery and optimised for touch devices, with full Veeva CLM, IREP and Salesforce integration. The stated result: Veeva CLM · IREP · Salesforce · Touch-optimised.
The project covers a different platform mix from the Novartis China work. Together they show hands-on integration experience across IREP, Veeva CRM, Veeva CLM, Vmobile and Salesforce, which is the combination many global brand teams have to support.
Ranbanka also created an eDetailer for Eli Lilly India's Trulicity product through Lebeyon. It features smooth animations, touch-device optimisation and seamless Veeva CLM and Salesforce integration. With Humalog, that makes repeat eDetailer delivery for Eli Lilly brands, across different products and platform combinations.
Shantanu Karmakar, Director - Business Planning & Client Services at Lebeyon Marketing Communications, described the partnership this way:
"Working with Ranbanka Systems has been a game-changer for us. Their expertise in frontend development and eDetailer solutions streamlined our document automation processes, making them faster and more reliable. Their team's attention to detail and commitment to delivering quality work on time truly set them apart. We look forward to continuing this partnership."
Working with an offshore eDetailer partner from the UK, US or Europe
Many agencies in the UK, US and Europe already work with offshore development partners. The question is how to do it without losing control of the client relationship or the quality bar.
An agency-friendly model
Ranbanka Systems is based in Udaipur, India, and serves clients in India, the USA, the UK and worldwide. It has delivered work through agencies, including pharma eDetailers via Lebeyon and enterprise frontend projects via VMLY&R. In this model, the agency stays client-facing and owns the strategy and relationship while Ranbanka handles the build. See the clients page for more.
Practical commitments
- NDA and confidentiality, which matters for unreleased brand and clinical content
- Response within 24 hours, which helps keep MLR revision cycles moving across time zones
- Free initial consultation to review your platforms, content and timeline before any commitment
Questions to ask any eDetailer vendor
Whichever partner you consider, ask:
- Which platforms have you actually shipped to? Ask for named projects per platform, not a list of logos.
- How do you separate shared content from platform code? Look for an adapter or abstraction approach rather than per-platform copies.
- How do you test on devices? Ask whether they test on real tablets inside the real CRM apps or only in browser emulation.
- How do you handle compliance revisions? Find out how quickly an approved MLR change can be applied and re-packaged for every platform.
Ranbanka's related services include eDetailer using Veeva CLM, UI/UX Design, and QA and Testing. See the services page for details, or read more about Ranbanka Systems.
Next steps: scoping your multi-platform eDetailer
Before you brief a developer, gather answers to these questions:
- Target platforms per market: which CRM/CLM each region uses, whether IREP, Veeva CRM, Vmobile, Salesforce or others
- Devices: tablet models, OS versions and orientation
- Languages: which markets need translations or market-specific claims
- Tracking requirements: which events and interactions must reach the CRM record
- MLR timeline: review rounds, approval dates and launch deadlines per market
- Existing design assets: source files, brand guidelines, fonts and any previous eDetailers to reuse
With that information, a capable partner can propose a shared codebase, an adapter per platform and a realistic delivery plan.
Browse the portfolio for the full set of eDetailer case studies, or explore more articles on the blog.
Ready to plan your next IREP eDetailer development project? Book a free consultation to review your platform mix and content plan with the Ranbanka team.