Case study · Sales Cloud for a pharmaceutical field team
From an empty org to a working field visit prototype in two weeks.
No doctor counted as contactable without a signed consent on file.
A pharmaceutical company selling to doctors and pharmacists in several EU countries was replacing a legacy CRM its representatives found hard to use on a tablet. I worked on the Sales Cloud prototype with a small delivery team: visit planning by institution, a visit report in one screen, product templates for the promotion cycle, and GDPR consent signed on the screen and stored as a PDF.
This is for you if your reps visit clinics, pharmacies or distributors, the visit lives in an old CRM or a spreadsheet, and nobody can say which high potential customers were not seen this month.
Developer org, 7 to 21 August 2026, changes in October. A prototype the client tested on its own logins, not a production system. The company is not named and none of its records are published. Reviewed 29 October 2026.
What changed
What changed for the field team?
Before: visits typed into a legacy CRM after the fact, consent on a paper form, management unable to see whether reps visited the right segments. Built: one plan per trip to an institution, the visit report in one screen, consent with a signature and a PDF. Now: the client's own people test the full visit, from plan to report, on their own logins.
2 weeks
from an empty org to a prototype the client ran end to end, plan to report
1 screen
for the whole trip instead of moving between four kinds of record
24 months
of validity on every consent, with the older consent superseded automatically
1 active template
per promotion cycle, copied into every new visit without retyping
Before
What was going wrong before?
The old CRM was hard to use and not built for a tablet, so visits were entered late and notes were not structured. History of each customer conversation did not carry over from visit to visit. Management could not see whether representatives were visiting high potential customers or only the convenient ones. Consent to contact a doctor was collected on paper, and without it the company may not contact that doctor at all.
What was built
Six changes, each one replacing a habit
A visit is planned for an institution, not for a doctor.
One plan per trip to a clinic, hospital or pharmacy, with a start, an end, a visit type and a status. Face to face, virtual call, round table, conference or mixed.
The whole trip is reported in one screen.
Who was there and who was actually seen, which products were discussed, the share of time on each, and which aspects came up: safety, dosage, availability, reimbursement, patient selection. A three step guided screen for the same job: participants, products, visit.
The promotion cycle arrives in the visit by itself.
Marketing sets a template: products, the target share of time for each, and the questions to ask. Only one template is active; activating a new one retires the old. Every new visit is filled from the active template.
Each institution shows its last and next visit.
A completed plan writes the last visit date onto the institution, a planned one writes the next. A planner on the home page lists institutions not visited since a chosen date, with their potential and loyalty, and the doctors in each with their consent status.
Consent is signed on the screen and kept as a PDF.
The rep opens the consent from the doctor's record, the doctor signs with a finger, and the signed form is saved as a PDF on the consent record. Status runs Draft, Active, Expired, Withdrawn, Superseded. Expiry defaults to 24 months. One flag on the doctor, "has active consent", is what every other screen reads.
Institutions and doctors loaded with territory and licences.
Institutions as accounts with potential A to E, loyalty 1 to 3, town, cluster and subcluster. A doctor can work in several institutions, and each licence, specialty and country is its own record. The same app runs on desktop and phone layouts.
The decisions that mattered
Which decisions are usually made the other way?
Plan the institution, not the doctor.
The usual build logs one calendar event per doctor. Reps do not travel to a doctor; they travel to a clinic and see whoever is free. Twelve events a day per rep is twelve chances to skip the paperwork, and coverage by institution cannot be reported at all. Here the trip is the record and the doctors are its participants, each marked seen or not.
Last and next visit written by a flow, not a roll-up.
A roll-up summary needs a master detail link, and a master detail link makes every visit plan inherit the institution's owner and sharing. In a field team the rep owns the trip, not the institution. So the plan keeps a lookup, and a small flow writes both dates when the plan's status changes.
Consent as a record, not a checkbox.
A checkbox on the doctor says yes or no and nothing else: not which text was signed, not when it lapses, not that it was withdrawn. Here each consent is its own record with the form version, the PDF and an expiry. When a new consent becomes active, the previous one is marked superseded, so a doctor never holds two live consents and the checkbox everyone reads is kept by the system, not by hand.
Lessons
What would I do differently next time?
Freeze a field type once a rule depends on it.
The product share was designed as a plain number so a rule could check that shares add up to 100. Midway it became a percent field, which a formula reads as 1, not 100, and the rule started blocking the very visits it was meant to check. Now any field a validation reads is listed, and a type change to it reopens the rule.
Write the Apex tests in the same week as the class.
A developer org deploys Apex without tests; production refuses anything under 75 percent coverage. Four classes behind the visit and consent screens had no tests at handover. Now no class leaves the sandbox without one.
Test as the representative, not as the admin.
Everyone who tested also had an admin or reviewer permission set, which hid that the plain rep set could not run the custom screens. Now every role gets a test user that holds that role's permissions and nothing else.
What buyers ask first
Three questions before you start
Do we need Salesforce's life sciences industry cloud for this?
Not for planning and reporting visits. Salesforce sells an industry cloud for life sciences with its own visit management, on its own licence. For a field team of a few dozen, the trip, participant, product and consent records shown here run on Sales Cloud with flows, a few screens and no extra licence. If you later need what that cloud adds, the data model maps across.
Will reps actually use it on a tablet?
The visit report was designed for a rep standing in a corridor between two doctors: one screen for the trip, mark several people seen at once, products already filled from the template. What the prototype did not settle is offline work; that stays an open requirement until the field team confirms how often it has no signal.
Is a signature on a screen enough for GDPR?
The text of the form is your legal team's decision, and in this project it was still with them. What the system adds is proof: which version of the form, signed by whom, when it lapses, and the PDF on the record. Renewal reminders and setting a lapsed consent to expired come next.
For your business
Which parts carry over to another field team?
Four of the six carry over to any company whose reps visit institutions: the trip as the record with participants under it, last and next visit on the institution, a template that fills each visit, and consent as its own record with a PDF. Medical devices, veterinary supplies and pharmacy distribution work the same way. The visit types, product aspects and territory list change with the business.
A quick test before anything else: open your CRM and list the ten institutions with the highest potential. For each, can you see the last visit date and whether every doctor there has a valid consent? If it takes longer than five minutes, that is the gap.
Limits
What was not part of this work
This was a prototype in a developer org, not production. Planned and actual cost tracking was in the original proposal and was removed by the client, who keeps costs in its own tool. Country level access, so that reps in one country do not see another's doctors, was designed, not built. Automatic quarterly refresh from the data provider, offline capture, consent forms in the other countries' languages and the Apex tests are open items for the build phase.
Next step
Next step
If your reps already log visits in Salesforce, or in a spreadsheet next to it, the one day check measures what your data can carry before any visit object is built: €650, one working day, read only, credited in full against work booked within sixty days.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 29 October 2026.
Read next
The question that usually comes after this one.
Sales Cloud Implementation Cost in 2026
Sales Cloud implementation from €11,310 for 174 hours: the seven decisions that move those hours, and why billed hours and elapsed weeks are different numbers.
Salesforce Permissions Audit: Fixed €650
Nine access risks a Salesforce permissions audit finds and why agents inherit them all. Check them yourself, or one fixed day at €650 against your exports.
Case: Group of companies, second rollout
A holding and its operating companies came back to Salesforce after a first rollout stalled: tenders as leads, one customer record in either alphabet, access proved as the users.