Publishing Permissions Belong in the Localization Workflow

The person who can request a translation should not automatically gain the power to publish it.

Translation, review, CMS delivery, and publication are separate actions with different consequences. When a localization tool compresses them into one permission, teams must choose between broad access and a slow, centralized process.

A better workflow preserves the boundaries the editorial organization already trusts.

Separate the important capabilities

At minimum, localization permissions should distinguish who can:

• create translation requests
• edit generated drafts
• approve localized content
• push approved values to the CMS
• publish or unpublish entries
• change project prompts, glossary rules, and automation

Small teams may assign several capabilities to the same person. The distinction still matters because it makes intent visible and lets the workflow grow without redesigning its security model.

Respect the CMS as the authority

A localization application should not become a shortcut around Contentful permissions.

If the connected user or integration cannot publish an entry in the selected environment, the localization workflow should not claim otherwise. It should verify the capability early, show that translation and push can still succeed, and describe the remaining publication step clearly.

This prevents a frustrating outcome where an editor reviews an entire batch only to discover at the end that no one in the workflow can complete it.

Make automation obey the same rules

Automatic push and publish are conveniences, not new sources of authority.

Automation should run under a defined identity with the narrowest permissions it needs. The request should record who enabled the rule, which project and environment it covers, and whether publication requires prior review.

If permissions change while work is queued, recheck them before the action. A setting captured last month should not override access revoked today.

Keep failure states precise

A permission failure during publication does not invalidate the translation.

Preserve the approved draft and any successful CMS update. Mark the publish phase as blocked, explain which capability is missing, and let an authorized person resume from that point.

Restarting the request wastes review work and obscures the real issue. Phase-specific state makes recovery both faster and more accountable.

Design for separation of duties

Some organizations require one person to prepare content and another to approve its release. The workflow should support that without relying on messages outside the system.

A reviewer can approve the language, a market owner can authorize the locale, and a publisher can release the entry. Each handoff should include the relevant preview, source snapshot, target changes, and audit history.

Separation of duties does not need to mean endless approval chains. Use it where risk calls for it and keep lower-risk content on a simpler path.

Audit decisions, not just API calls

Technical logs can prove that an endpoint returned success. Editorial audits need more context.

Record who approved the draft, which fields were pushed, which environment received them, who initiated publication, and what version went live. When automation acts, record the policy and identity behind it.

That history helps teams answer a release question without reconstructing it from several systems.

The takeaway

Localization moves content across boundaries of language, systems, and authority.

Separate request, review, push, and publish capabilities. Honor current CMS permissions, apply the same controls to automation, and preserve successful work when a later phase is blocked. Clear permission boundaries let teams move quickly without granting every participant the keys to the final release.