GREENLIGHT ADVISORY · CLINICAL RESEARCH OPERATIONS
The Clinical Research Salesforce Workflow Visibility Guide
A practical self-assessment for integrated site networks, decentralized research organizations (DROs), and hybrid operators that need clearer visibility from prospecting and feasibility through startup, recruitment, and First Patient In.
Most clinical research organizations do not have a Salesforce problem.
They have a workflow visibility problem.
This guide helps you evaluate whether Salesforce supports the full path from prospecting and RFP intake through feasibility, proposal, contracting, startup, recruitment, and First Patient In — for teams managing research across multiple sites, service models, vendors, and concurrent studies.
Integrated Site Networks
Decentralized Research Organizations
Hybrid Operators
John Sprankle
Founder & Principal Advisor · Salesforce Architecture, sub-specialized in clinical research
Built from firsthand Salesforce architecture experience inside large-scale decentralized and hybrid clinical research operations.
greenlightadvisory.io · j.sprankle@greenlightadvisory.io
Introduction
Where Salesforce visibility breaks between sales and First Patient In.
Most integrated site networks, decentralized research organizations, and hybrid operators already use Salesforce for some version of sales or business development. The problem is that the operational lifecycle often does not follow the same structure.
RFPs, protocols, CDAs, feasibility data, site selection, contract status, startup milestones, recruitment activity, and enrollment visibility may live across Salesforce, spreadsheets, email threads, shared drives, CTMS reports, vendor trackers, and recurring status meetings. That fragmentation makes it harder to answer the questions leadership actually cares about:
- Which studies are worth pursuing?
- Which opportunities are feasible?
- Which sites or services are ready?
- What is blocking activation?
- Which studies are at risk of missing First Patient In?
- Where should automation or AI be applied — and where would it create risk?
A few definitions, used consistently throughout
Greenlight — the point at which a site, service model, or study workflow is operationally ready to begin enrollment, based on the organization's defined activation criteria.
First Patient In (FPI) — depending on the sponsor, CRO, or protocol, this may mean first patient consented, screened, enrolled, randomized, or dosed. Where possible these should be tracked as separate milestones rather than one undefined date.
DRO — Decentralized Research Organization.
Who this guide is written for
Network / Commercial Leader
Your BD pipeline is in Salesforce; your multi-location operational lifecycle probably is not. See what the full architecture looks like — and where revenue leaks through slow activations.
Clinical Operations / Site Network Leader
You run concurrent studies across owned and decentralized locations. Get the framework to demand real-time visibility across sites, services, and activation status.
Feasibility / Study Startup Manager
You know what's slow operationally. Get the vocabulary to drive the right Salesforce architecture conversation with your admin team.
Salesforce Admin in Life Sciences
You know the platform but may lack deep clinical-research context. This maps the objects, relationships, and automation that belong at each stage.
The Framework
The seven stages from prospecting to First Patient In.
Greenlight Advisory evaluates Salesforce across the full path from commercial pursuit to enrollment execution. The key question is not whether Salesforce contains records for each stage — it is whether Salesforce connects the handoffs between stages clearly enough for leadership to trust the operating picture.
| Stage | What Salesforce should help clarify |
| 1.Prospecting | Which sponsors, CROs, therapeutic areas, and studies are worth pursuing. |
| 2.Opportunity / RFP Intake | Whether the right study details, protocol requirements, deadlines, and buyer needs have been captured. |
| 3.Feasibility | Whether the organization can realistically deliver the required patients, sites, services, geography, timeline, and cost. |
| 4.Proposal, Budget & Contracting | Whether the proposed scope, pricing, assumptions, and enrollment commitments are operationally realistic. |
| 5.Site / Service Activation Planning | Whether awarded work has been translated into site, service, team, vendor, and workflow readiness. |
| 6.Study Startup | Whether regulatory, contracts, systems, vendors, recruitment, and site/service operations are ready to open enrollment. |
| 7.First Patient In / Enrollment Launch | Whether the study has moved from startup into active enrollment execution, based on the sponsor's definition of FPI. |
The detailed operational review that follows focuses on the five stages where most visibility is lost in practice: opportunity and feasibility, site and service selection, startup and regulatory, recruitment, and enrollment visibility.
Read the sequence, not a stopwatch. The stages describe a typical order, not a universal timeline. Actual timing depends on protocol complexity, geography, sponsor/CRO process, regulatory path, contract cycle, and site/service readiness. Read the lifecycle as a critical path — CDA → SSV → IRB/EC → SIV → greenlight → First Patient In — where every handoff that lives in email instead of Salesforce is a place the timeline slips.
Typical sequence · Early pursuit · BD, Commercial
Automation
The commercial front end. Salesforce should help decide which sponsors, CROs, and studies are worth pursuing — before an RFP is in hand — and prioritize pursuit effort against strategic fit and history, not gut feel.
Process milestones
- Target sponsors, CROs, and studies identified
- Therapeutic-area and strategic fit assessed
- Opportunity logged in the commercial pipeline
- Account intelligence and relationship history reviewed
- Pursuit priority and go-forward decision documented
Salesforce architecture
- Opportunity (pipeline) — sponsor, CRO, therapeutic area, pursuit stage
- Account (Sponsor / CRO record type) — relationship + prior engagements
- Target-study pipeline report and pursuit-priority field
- Record-type structure separating pursuit from operational study
Automation & AI
- Pursuit prioritization scoring on the Opportunity
- Sponsor / CRO activity summaries
- AI: account-fit scoring against your strategic focus
Leakage check
- Is prospecting tracked in Salesforce — or in spreadsheets and inboxes until an RFP forces a record?
- Is there structured fit-intelligence to prioritize pursuits — or is prioritization a judgment call?
- Does pursuit priority live in a field leadership can report on — or in individual heads?
02
Opportunity / RFP Intake
Typical sequence · Intake · BD, Proposals, Feasibility
Automation
Once a study is worth pursuing, the question is whether its details enter Salesforce as structured data — or as email, attachments, and notes nobody can report on.
Process milestones
- RFP / Protocol Synopsis received and logged
- Service model requested captured
- Buyer needs and submission deadline recorded
- CDA sent, signed, and expiry tracked
Salesforce architecture
- Clinical Study (or Study Intake) record created at the qualification point
- CDA object — sent, signed, expiry fields
- Protocol Synopsis attachment handling
- Intake-completeness flags
Automation & AI
- CDA expiry reminder flow — automatic notification
- AI: protocol synopsis analysis — extract key parameters
- AI: missing-intake-information detection
Leakage check
- Is RFP/protocol intake a structured record — or a forwarded email?
- Is CDA status (sent, signed, expiry) a field you can gate feasibility on — or a note?
- Is the service model requested captured at intake — or discovered later?
Typical sequence · Feasibility · Feasibility, Finance
AI-ready
Feasibility is where Salesforce should MAKE the pursuit decision better — not just document it after the fact. That requires structured, scored, reusable feasibility intelligence.
Process milestones
- Feasibility survey distributed across the network
- Site responses captured and scored
- Patient prevalence and timeline estimates compiled
- Competing-trial burden assessed per site
- Operational risk and go/no-go decision documented
Salesforce architecture
- Feasibility Survey object — site responses, scores
- Site Profile — reusable feasibility intelligence across studies
- Complexity Score formula field
- ACV and enrollment-assumption fields
Automation & AI
- Feasibility survey distribution triggered by stage change
- Auto-calculate complexity score on save
- AI: site/service matching — score network against protocol
- AI: feasibility risk summaries
Leakage check
- Is feasibility captured in a scored object — or in a spreadsheet and email?
- Does a Site Profile store reusable history — or does every study start feasibility from scratch?
- Is the go/no-go decision data-driven — or documented after it is already made?
04
Proposal, Budget & Contracting
Typical sequence · Contracting · Contracts, Legal, Finance
Highest automation ROI
This is the award-to-operations handoff — the most commonly missing structure in a site-network build, and where most execution problems begin. What the sale promised must be structured enough for operations to execute.
Process milestones
- Proposal scope and pricing defined
- Budget assumptions and enrollment commitment locked
- CTA / MSA / Work Order negotiated and executed
- Startup-fee trigger confirmed
Salesforce architecture
- Clinical Trial Agreement (CTA) object — status, execution date
- Work Order / Budget object — version, approval routing
- Enrollment-commitment field carried forward into operations
- Base contract value locked for ACV reporting
- Handoff / launch-packet record
Automation & AI
- Budget approval routing flow
- Contract cycle-time stopwatch (draft → execution)
- AI: proposal assumption checks
- AI: budget-risk flags
Leakage check
- Are CTA, budget, and work orders tracked as startup-critical milestones — or in a contract tool operations cannot see?
- Does the enrollment commitment made in the sale carry into operations — or get re-discovered at startup?
- Is there a structured handoff packet — or does operations re-litigate scope after award?
05
Site / Service Activation Planning
Typical sequence · Activation planning · Ops, Sites, Vendors
AI-ready
Translating awarded work into an execution plan. For decentralized and hybrid operators, selection intelligence has to compound — every SSV outcome updates the Site Profile so the next study starts from history.
Process milestones
- Site / service model matched to protocol
- Site Selection Visit (SSV) — remote or in-person
- PI suitability, availability, and GCP status confirmed
- Infrastructure, staff, and vendor/service readiness evaluated
- Team assignment and workflow ownership defined
- Qualification decision documented
Salesforce architecture
- Site record (Account) — infrastructure and staff fields
- SSV milestone object — date, type, outcome
- PI Contact — CV, certification, availability
- Site Qualification Scorecard — composite scoring
- Study-Site Junction with per-site status
- Vendor / service readiness fields
Automation & AI
- SSV scheduling notification to the coordinator
- PI commitment follow-up if no response in a set window
- Auto-update site status when qualification criteria are met
- AI: site/service performance prediction from history
- AI: PI matching against protocol therapeutic area
Leakage check
- Is there a Study-Site (or Study-Service) junction enabling per-unit tracking across concurrent studies?
- Is qualification a scored, documented decision — or a judgment call?
- Is the Site Profile updated after each study so selection intelligence compounds?
Typical sequence · Startup · Regulatory, Startup
Highest automation ROI
The least-visible, most operationally fragile interval before enrollment. Define and standardize your activation criteria before building the activation-% calculation.
Process milestones
- Regulatory packet compiled — Form 1572, CVs, financial disclosure
- IRB / IEC submission and approval
- Essential documents complete per site
- Site Initiation Visit (SIV) — GCP, protocol, EDC training
- Systems access and recruitment setup complete
- Site activated — greenlight confirmed
Salesforce architecture
- Regulatory Packet object — completeness checklist per site
- IRB / IEC Submission object — date, approval, expiry
- SIV Milestone — scheduled, completed, training attestation
- Activation % formula — units meeting activation criteria ÷ total selected
- Greenlight dashboard — real-time portfolio view
Automation & AI
- Regulatory packet completeness check — auto-flag missing docs
- IRB submission deadline reminder flow
- SIV scheduling triggered when IRB approval is received
- Greenlight notification to the enrollment team on activation
- AI: IRB timeline prediction from historical data
Leakage check
- Is the essential-document checklist tracked per site in Salesforce — or in a spreadsheet?
- Is IRB/IEC status tracked with dates and amendment history?
- Is activation % calculated automatically — or delivered as a manual update?
07
First Patient In / Enrollment Visibility
Typical sequence · Enrollment launch · Operational visibility only
Visibility
Salesforce is an operational visibility, workflow-handoff, and executive-reporting layer here — integrated with the validated source systems, not replacing them. Define First Patient In explicitly: it may mean first consented, screened, enrolled, randomized, or dosed.
Process milestones
- Recruitment campaigns live by site and channel
- Pre-screening and I/E evaluation; failures logged (aggregate)
- ICF reviewed and signed; screening visit conducted
- Patient enrolled and randomized into trial arm
- First screened / enrolled / randomized / dosed captured per the sponsor's FPI definition
Salesforce architecture
- Recruitment Campaign object — channel, site, lead volume
- Pre-Screen record — pass/fail, reason codes, attribution
- ICF tracking — aggregate milestone status, no PHI
- Screen Failure log — reason codes, counts per site
- Enrollment record + dashboard — velocity, forecast vs. actual
Automation & AI
- Pre-screen pass/fail scoring against I/E criteria
- Enrollment velocity alert when a site falls below target
- AI: enrollment velocity forecasting vs. protocol timeline
- AI: screen-failure pattern detection where data supports it
Leakage check
- Is Salesforce receiving enrollment visibility from the source system — or is leadership relying on manual updates?
- Are screen-failure reason codes captured in aggregate — allowing pattern detection across sites?
- Is the enrollment dashboard trusted by leadership — or reconciled against a spreadsheet before every call?
An Important Boundary
What Salesforce should not replace.
A well-designed clinical research Salesforce build is powerful. It is not a replacement for the validated, regulated systems that run clinical trial data. Salesforce serves as the operational workflow, handoff, visibility, and executive-reporting layer — integrated with regulated systems where appropriate.
| EDC | Source of truth for patient clinical data, adverse events, and protocol deviations. Salesforce may receive aggregate data — it does not replace it. |
| CTMS | Some organizations use a dedicated CTMS for study-level operational tracking. Salesforce can complement a CTMS in specific contexts — a deliberate architectural decision. |
| eTMF | The regulated repository for essential trial documents. Salesforce can track document status and completeness milestones — it is not a validated eTMF. |
| eConsent | Validated system for informed-consent capture. Salesforce may track ICF milestone status in aggregate — it does not replace eConsent. |
| IRT / RTSM | Randomization and trial supply management. Salesforce may receive enrollment data from IRT — it does not replace it. |
| Safety / PV | Adverse-event intake, case processing, and regulatory safety reporting belong in validated safety/PV systems and governed safety workflows. Salesforce should not be positioned as the safety system of record. |
Vendor Services
Managing clinical vendors in Salesforce.
Central labs, imaging, eCOA, IRT, translation, and recruitment vendors are a distinct workflow most builds ignore entirely — selection and performance end up in email, with no study-level visibility.
| Vendor Services Request | Initiates a vendor engagement. Captures category, requirements, RFI/RFP status, selection status, scope, and budget approval. Linked to the Clinical Study record. |
| Vendor Services Engagement | Child of the request. Tracks the active engagement — SOW/MSA status, kickoff, deliverables, milestones, issue and escalation tracking, and a performance scorecard. |
| Account (Vendor) | The vendor is an Account record type — relationship data, historical performance ratings, and prior-engagement data reusable for future selection decisions. |
Maturity Model
The Clinical Research Salesforce Workflow Maturity Model.
Five stages of Salesforce maturity mapped to decentralized and hybrid clinical research operations. Most organizations have the least structure precisely where they have the most to gain.
1Spreadsheet Dependent
Salesforce tracks basic commercial activity. Feasibility, startup, site/service readiness, recruitment, and enrollment visibility live mostly in spreadsheets, email, shared drives, CTMS exports, and status meetings.
2Partial Pipeline Coverage
Salesforce supports the BD pipeline and some study intake. Feasibility, startup, and recruitment data may be partially captured, but handoffs are inconsistent and leadership reporting requires manual reconciliation.
Common ISN / DRO pattern — you are likely here3Connected but Incomplete
A Clinical Study or operational study record exists. Study-site or study-service tracking may exist. However, feasibility history is not consistently reused, activation criteria are unclear, recruitment visibility is fragmented, vendor/service readiness is inconsistently tracked, and enrollment reporting still requires manual cleanup.
4Lifecycle Coverage
Salesforce supports the full path from prospecting and RFP intake through feasibility, proposal, contracting, activation planning, startup, recruitment, and FPI visibility. Handoffs are defined, key milestones are structured, and leadership can rely on dashboards without extensive manual reconciliation.
5AI-Ready Operations
Salesforce data is standardized across the lifecycle. Feasibility history, site/service performance, startup milestones, recruitment performance, and enrollment visibility are clean enough to support AI-assisted summaries, recommendations, forecasting, and decision support — with human review and governance in place.
Common Build Errors
Three mistakes that slow the path to First Patient In.
1
Forcing the Opportunity object to carry the full clinical study lifecycle.
The Opportunity object is appropriate for commercial pursuit, forecasting, and proposal management. It becomes a problem when it is forced to carry feasibility, startup, regulatory, site/service activation, recruitment, and enrollment visibility without a dedicated operational data model — architecture that breaks at scale and is expensive to correct later.
2
Building the BD pipeline and stopping.
The commercial pipeline is usually the first Salesforce workflow to be built. For clinical research operators, the greatest operational value often appears after RFP intake or award: feasibility reuse, site/service readiness, startup milestone tracking, recruitment visibility, and FPI risk management.
3
Investing in AI before the data foundation is ready.
AI on unstandardized, incomplete, or untrustworthy data produces unreliable outputs at speed. Site-matching AI needs a structured Site Profile with history; feasibility pre-population needs structured prior responses; enrollment forecasting needs consistent milestone data. AI should support human review and decision-making — it should not independently determine feasibility, eligibility, enrollment commitments, or site selection without governance.
What to Fix First
If your build reflects the Stage 3 pattern, start here.
Each can be scoped, architected, and handed to your internal Admin to execute.
1
Verify or design the Study-Site (or Study-Service) Junction.
Without it, per-unit milestone tracking across concurrent studies is unreliable. For networks running many studies across many locations and service models, this is the architectural foundation for everything in startup.
2
Design the Site Profile.
Eliminates the most consistently documented feasibility inefficiency — sites re-entering the same information for every study. Also creates the data foundation for AI-assisted site matching once history is sufficient.
3
Design the activation % calculation.
A formula on the Clinical Study record: sites or services meeting activation criteria ÷ total selected. Gives leadership real-time activation visibility without a status meeting. Define and standardize your activation criteria first — then your Admin configures it in an afternoon.
Automation & AI Readiness
Where automation and AI belong — and where they don't yet.
Automation and AI are only useful when the workflow is clear and the data foundation is reliable. Greenlight Advisory evaluates where Salesforce can support practical automation and AI-assisted workflows across the clinical research lifecycle.
Practical automation opportunities
- RFP and protocol intake routing
- CDA and qualification tracking
- Feasibility survey distribution
- Site / service selection workflows
- Activation checklist automation
- Regulatory and CTA milestone reminders
- Recruitment funnel alerts
- Enrollment milestone notifications
- Award-to-operations handoff checklists
AI-assisted opportunities
- Protocol summary and key-field extraction
- Missing intake information detection
- Protocol complexity scoring
- Site or service match recommendations
- Feasibility risk summaries
- Go / no-go decision support
- Proposal assumption checks
- Startup readiness summaries
- Enrollment visibility summaries
An important boundary
AI should be used as decision support, not autonomous decision-making. Advanced use cases such as enrollment forecasting, site performance prediction, and screen-failure pattern detection require clean historical data, clear governance, and appropriate privacy/security controls. The foundation comes before the AI.
The Next Step
Get an independent Salesforce workflow review.
The Clinical Research Salesforce Workflow Audit is a fixed-fee review of how your current Salesforce environment supports the path from prospecting and feasibility through startup, recruitment, and First Patient In. It is designed for integrated site networks, decentralized research organizations, and hybrid operators that already use Salesforce but need a clearer view of what is working, what is missing, and what to improve first. No software to sell. No vendor agenda. No implementation dependency.
7
stages assessed — from prospecting to First Patient In
48–72h
delivery · no Salesforce access required to start
14 days
credit window toward an advisory engagement
$2,500 flat fee · credited toward an advisory engagement started within 14 days · 60-minute executive review call included
You complete a structured intake at your own pace — no Salesforce access needed. John analyzes it against the framework and delivers specific findings. Because the fee credits toward an engagement started within 14 days, the diagnosis effectively becomes step one of the build. Your team executes; there is no build dependency on Greenlight.
What the audit delivers
- Lifecycle gap map — stage-by-stage coverage
- Automation opportunity map — ranked by impact on First Patient In
- Object model assessment — Clinical Study, Study-Site Junction, Site Profile, Vendor Services
- AI-readiness score per stage — with specific data prerequisites
- Decentralized & hybrid site/service workflow review
- Executive summary for leadership
- Essential document & regulatory milestone review
- 30-day prioritized roadmap your Admin executes
- Recruitment pipeline & pre-screening compliance assessment
- 60-minute executive review call — walk every finding together
- Enrollment visibility & source-system integration review
- Independent throughout — no software to sell, no vendor agenda