Roles, governance and workflows for scaling self-service authoring: who owns each decision across global and local teams, what markets can change, and how a source update reaches the materials already in use.
Platform access is only part of the work. To scale self-service authoring, local teams need clear authority to act, defined review requirements and named owners who maintain content after approval.
Start with decisions, not an org chart. Map one content flow and record, for each decision, the owner, the required inputs, the review path and the escalation route.
Business ownership and MLR approval are separate decisions. A local owner remains responsible for their material; the applicable MLR function decides its approval.
Define adaptation boundaries by the nature and impact of a change, not by the percentage edited. Permission to edit is not permission to release.
Ownership continues after approval. A source change triggers an impact assessment, local owners update or withdraw their materials, and completion is recorded. Traceability locates affected assets; it never approves them.
Pilot before you expand. Test the model against a real adaptation and a source change, and resolve unclear ownership before adding markets or brands.
A pharma content operating model defines how teams create, review, approve, adapt, reuse, maintain and retire content. It connects decision rights and global–local responsibilities with the workflows and technology needed to carry them out. For self-service authoring to scale, teams need clear authority to act, defined review requirements and named owners for maintaining content after approval.
Giving local teams access to an authoring platform is one part of that work. Teams also need to know which content they can use, what they can change, who resolves exceptions and how updates reach materials already in use.
In an earlier interview, I explored why governance and adoption can limit pharma content operations. This article translates that perspective into a practical framework for assigning responsibilities and designing workflows. It is a starting point to adapt to your organisation, markets and approved procedures.
Start with the decisions your teams need to make
Choose one content flow to map, such as a global campaign adapted into local approved emails. Include local content owners and medical, legal and regulatory (MLR) reviewers early, so that the design reflects how work happens in each market.
List the decisions that arise throughout that flow: who sets the message, authorises adaptations, approves the finished material, handles source updates and withdraws outdated versions. For each decision, record the owner, the required inputs, the review path and the escalation route.
The model covers people, processes and technology. Defining the decisions first helps you understand which responsibilities need to be formalised and which rules the platform must support.
Content strategy determines what to communicate, to whom and why. The operating model establishes how teams deliver and maintain that content consistently. Modular content is a key element of a scalable operating model; where it is used, the operating model also governs how reusable modules are maintained and used in finished assets.
Assign ownership at global and local levels
The following functions provide a manageable starting point. One person may hold several responsibilities, but each decision should have an identifiable owner.
GlobalGlobal Content or Brand OwnerOwns global messaging, source content and business decisions about updating or retiring it.
LocalLocal Content OwnerOwns local materials, carries out permitted adaptations and coordinates local updates or withdrawal. This may be a local brand manager or market coordinator.
ReviewMLR functionPerforms the required review and approval. Identify the relevant global or local reviewers for each decision; the function is not a single universal approver.
EnablementContent Operations or Platform LeadMaintains the operating model, coordinates traceability and enables workflows. Business administrators manage routine platform configuration and access within this function, with IT support for changes that require it.
An Executive Sponsor supports cross-functional decisions and resolves issues that the operating team cannot settle. Define when escalation is appropriate, rather than making sponsorship another routine approval step.
An illustrative RACI for content operations
A means accountable for the decision; R means responsible for carrying out the work; C means consulted; I means informed. A/R indicates that the same function holds both responsibilities. Adapt this matrix to your procedures and assign named people to each function.
Decision or activity
Global owner
Local owner
MLR
Content Ops
Set global messaging and business objectives
A/R
C
C
C
Approve a claim or finished asset through the applicable MLR process
C
C
A/R
I
Prepare a permitted local adaptation
C
A/R
C
C
Decide whether to update or retire global source content
A
C
C
R
Identify affected derivatives and cascade a source change
A
I
C
R
Update or withdraw affected local materials
C
A/R
C
C
Configure role-based access and content distribution
C
C
C
A/R
AAccountable
RResponsible
CConsulted
IInformed
Table 1. An illustrative RACI for one content flow. It is a starting point, not a universal procedure: adapt it to your organisation and name a person for each function.
Business ownership and MLR approval are separate decisions. A local owner remains responsible for their material, while the applicable MLR function determines its approval through the required process. For local updates, specialised roles such as Label Stewards can support the workflow without removing ownership from the local team.
Define adaptation boundaries and review requirements
Document the permitted changes for each content type and market. Distinguish permission to edit from permission to release the resulting material. A local team may be authorised to prepare an adaptation that still requires review before use.
Define boundaries by the nature and impact of a change. The percentage of content edited is not a reliable substitute: a small change can alter a claim, its supporting evidence or its meaning.
Permitted adaptations
Defined changes local teams can make within approved boundaries, with a documented release path.
Consultation first
Uncertain cases go to a named person or function, and the decision is recorded for every market to reuse.
Formal review
Triggers set in your approved procedures, such as changes to claims, evidence, references, meaning or context.
The three kinds of change to define for each content type and market.
Permitted adaptations
Specify which elements local teams can change, the conditions that apply and the required release path. Examples may include localised data, tailored messages, designated contact details or defined layout options. Local teams create assets that align with approved core brand elements, standards and implementation guidelines, which are embedded in the authoring tools. Translations and adjustments for local labels, regulatory requirements, epidemiological data or reimbursement conditions may also be needed, together with minor branding modifications to meet local standards, but their review requirements must be established explicitly.
Changes requiring consultation
Name the person or function that resolves uncertainty about an adaptation. Record the decision so that the same question does not need to be reconsidered independently in every market, and define an escalation route for unresolved questions. Typical triggers include creating derivative or amplified content.
Changes requiring formal review
Specify the triggers in your approved procedures. These may include changes to claims, evidence, references, meaning or the context in which content is used. Previously approved components do not, by themselves, settle whether a finished asset needs review.
An abbreviated update path may be appropriate for defined changes where the organisation’s approved procedures permit it. Platform workflows should implement those procedures; the configuration itself does not determine whether review is required.
Govern the content lifecycle after approval
Define the initial path from drafting through review and approval to availability for use or reuse. Then document the separate paths for adaptation, updating, expiry and retirement.
Initial path
Draft
Review
Approve
Available for use and reuse
Then a documented path for each of
Adaptation
Update
Expiry
Retirement
Figure 1. The lifecycle paths to document, for finished assets as well as reusable modules.
An adapted or updated version follows the applicable review and release requirements before use. A source change triggers an assessment of affected derivatives. Superseded or expired content is removed from availability according to the organisation’s procedures, while records needed for traceability are retained.
At each transition, identify who initiates the action, who decides, who executes and how completion is confirmed. Include finished assets as well as reusable modules, so that lifecycle ownership extends to the materials markets actually use.
Apply the model to a source content update
The following illustrative example shows how the responsibilities connect. It is not a customer case or a universal review procedure.
A global source module changes. The Global Content Owner identifies that a module needs updating following a change to its supporting source. Content Operations uses recorded relationships between the source, module and derived assets to identify potentially affected materials. Where specialised roles manage label changes, they support this assessment.
The global team communicates the action. The global owner and relevant reviewers determine the action for the source content. Content Operations coordinates a notification that identifies the changed version, the affected derivatives, the required actions and the applicable deadlines or escalation route.
Local owners assess and update their materials. Each local owner checks the impact on their market’s materials, prepares the required updates and follows the applicable local review procedure. If withdrawal is required, the local team coordinates removal from the relevant distribution channels. Global teams provide source information and support; local teams own execution for their materials.
Completion is recorded. The local owner confirms that affected materials have been updated or withdrawn. Content Operations tracks outstanding actions and escalates gaps to the named owners. The record preserves the relationship between the source change and the resulting local versions.
Traceability supports impact assessment. It does not mean that a source update can automatically overwrite approved local assets or release them without the required decisions.
Configure technology around the agreed workflow
Use the operating model to define requirements for authoring, approval, repository and distribution systems. Depending on your ecosystem, responsibilities may be shared across several platforms.
Map access to roles, markets and content scope. Business administrators handle routine configuration; IT supports exceptional technical changes.
Preserve links between source content, modules, references and local derivatives, including version and lifecycle information.
Support approved templates, editing boundaries, review routes and records of decisions.
Connect the systems that make the rules enforceable: a digital asset management (DAM) repository, an enterprise design system that holds core brand elements and standards, and automation tools for scalable content assembly.
Assign responsibility for publishing approved assets to content hubs or portals, and for removing superseded versions from availability.
For the modular-content component of this design, see our article on modular content strategy, from pilot to scale. It covers reusable content structure and implementation; this operating model assigns the responsibilities around that work.
Build adoption and local feedback into the model
Assign an owner for onboarding and ongoing enablement. Local teams need guidance on the tasks they perform, the content available to them and the decisions they can make. Training should include how to raise exceptions and what happens when source content changes.
Bring local teams into planning before global assets are finalised. Global teams should co-create core content with local teams rather than working in silos, and local MLR reviewers need early visibility of timelines so they can give input ahead of launch. Their feedback can reveal missing content, unsuitable templates or adaptations that recur across markets. Give the Global Content Owner a defined route to review that feedback and update source content or guidance.
Content Operations should use support questions and escalation records to identify recurring friction. If several markets ask the same question, update the guidance, workflow or configuration that caused the uncertainty.
Measure how the operating model performs
Set a baseline within the pilot and compare similar content types and markets as the programme expands. Use measures that show whether responsibilities and workflows are working in practice.
Routine escalations per local asset. Record why teams escalate and which questions recur. A reduction can indicate clearer decision rights, provided required consultations still occur.
Time to action a source change. Measure from notification to confirmed update or withdrawal. Separate the time spent assessing impact, preparing changes and obtaining required approval.
Completion within agreed deadlines. Track the share of identified affected assets updated or withdrawn on time, alongside any unresolved traceability gaps.
Self-service adoption. Track the share of eligible adaptations completed by local teams using the agreed workflow, alongside support needs and quality measures.
Monitor MLR outcomes separately, including the reasons for rework. Faster handling is useful only when it preserves the required review and content quality.
Agree the outputs before expanding
Before adding more markets or brands, confirm that the pilot has produced:
Pilot readiness checklist
Named global and local owners, with decision rights and escalation routes documented.
Permitted adaptation rules and review triggers for the chosen content flow.
Review tiering policies and guidelines.
Update, withdrawal and retirement procedures covering source content and derivatives.
Configured access, version relationships and a defined process for resolving traceability gaps.
Task-based onboarding, an owner for support and a route for local feedback.
A shared understanding of what modular content is and the value it delivers.
The ability to track operational flow, engagement, adoption and reuse of modular content.
A baseline for operational measures and a scheduled review of recurring friction.
Test the model against a real adaptation and a source-change scenario. Resolve unclear ownership before expanding the same workflow to additional teams.
Put the framework into practice
Start with one content flow, document its decisions and test how responsibilities work during an adaptation and a source update. Use the results to improve the model before expanding.
At Shaman, we combine self-service content authoring with support for content systems and user adoption. Our Content Excellence team can help you assess how roles, governance and workflows support your existing technology, and where operational changes would make the greatest difference.
A pharma content operating model defines the responsibilities, decision rights, workflows and technology used to create, approve, adapt, reuse and maintain content. For self-service authoring, it establishes what global and local teams can do, which actions require review and who keeps source content and derivatives current.
Who owns local adaptations of global content?
The named Local Content Owner owns the local material and coordinates its adaptation, maintenance and withdrawal. The global owner maintains the source and communicates relevant changes. The applicable MLR function retains its approval responsibilities under the organisation’s procedures.
What happens when a source module changes or expires?
The organisation identifies affected derivatives, assesses the impact and assigns update or withdrawal actions to their owners. Traceability helps locate those materials. Local owners follow the applicable procedures and confirm completion; a source change does not automatically approve a revised local asset.
How should exceptions be escalated?
Define an escalation owner for each type of question, such as content strategy, regulatory interpretation or platform configuration. Record the resolution and update guidance when the same exception recurs. Cross-functional issues that remain unresolved can go to the Executive Sponsor.
Does pre-approved content remove the need for local MLR review?
Not automatically. Review requirements depend on the market, the finished material, its intended use and the organisation’s approved procedures. Reusing approved content can support review efficiency, but approval of a source module does not automatically establish approval of every adaptation or assembled asset.
Can the operating model be designed before selecting new software?
Yes. Teams can agree ownership, decision rights and lifecycle requirements before choosing or reconfiguring technology. Assess existing systems against those requirements, then identify any gaps in authoring, review, traceability or distribution.
Jindrich has nearly 20 years of experience across enterprise platforms and content operations, including 10+ years at MSD (Merck), where he led a global team of 40+ IT professionals and drove global rollouts of Veeva Vault PromoMats — and before that, Microsoft’s Global Marketing Operations. He leads Shaman’s Content Excellence Practice. Connect on LinkedIn.
Jindrich Borovsky
