PADI editorial workflow review — please confirm the sections marked with questions
PADI — editorial workflow and permissions
This document explains how content will be managed on the new padi.com. Please review each section and confirm the questions marked with ? so we can finalise the build.
In the new site, there will be six user roles. Each person on the editorial team gets one role. That role defines exactly what they can and cannot do — which content they can touch, and whether they can publish it or only submit it for review.
Role
Create
Edit
Submit
Approve
Publish
Archive
Content they can access
Administrator
✓
✓
✓
✓
✓
✓
Everything — no restrictions
Content Manager
✓
✓
✓
✓
✓
✓
All content, all languages, all regions
Content Editor
✓
✓
✓
—
—
—
Their assigned region only
Blog Author
✓
✓
✓
—
—
—
Blog articles only
Blog Editor
—
✓
—
✓
✓
✓
Blog articles only
Translator
—
✓
✓
—
—
—
Translated versions of content only
We need your input on these
?
Should Content Editor be one role with regional restrictions, or do you want separate Global and Regional Editor roles?
?
Can you share a list of all existing team members and their current access levels so we can map them to the new roles?
?
Who on the PADI side will decide which role each person gets?
Every piece of content on the new site starts in Draft and goes through a review process before it goes live. No content can be published without passing through the right stages first. Content can always be sent back to Draft if changes are needed.
How it works
1
A Blog Author writes an article. It sits in Draft and is not visible to anyone else yet.
2
They submit it. It moves to Initial Review and the editor gets notified.
3
If the article needs to be translated, it moves to Translate. The translator works on it and sends it back. (Pending confirmation — see questions below.)
4
The editor does a Final Review and approves the article.
5
The article goes Live. A Content Manager can prepare an update in the background without taking the live article down.
Draft
→
Initial review
→
Translate
→
Final review
→
Live
→
Archived
Dashed border on Translate = pending your confirmation. See questions below.
Action
Who can do this
Submit for review
Content EditorBlog Author
Send to translation
Content ManagerBlog Editor
Submit translated content for final review
Translator
Approve and publish
Content ManagerBlog Editor
Send back to Draft for changes
Content ManagerBlog Editor
Update a live article without taking it down
Content Manager
We need your input on these
?
Does this workflow match how your editorial team actually works or does it need adjustments?
?
Does translation need to be a separate step in this workflow or does it happen through a separate process?
?
When content is sent back to Draft for changes, should the original author be the only one who can resubmit it or can any editor resubmit?
?
Should Blog Manager and Content Manager have the same permissions or are there differences in what they can access?
Editors can set a future date and time for content to go live automatically. They can also set a date for content to be taken down automatically. Every change to any content is saved as a version so editors can view the full history and restore any previous version if something goes wrong.
Scheduling — example
1
A Content Manager finishes a holiday campaign article and sets it to go live on 1 December at 9am and come down on 5 January.
2
On 1 December at 9am it goes live automatically. On 5 January it comes down automatically. No one needs to be online for either.
Updating a live article
1
A Content Manager clicks Create new draft on a published article. The live article stays live and unchanged while the update is being prepared.
2
The new draft goes through the normal review and approval process.
3
Once approved, the new version replaces the live article. The previous version is always saved and can be restored.
Version history
1
Every save and every workflow transition creates a new version with a timestamp and the name of the person who made the change.
2
Editors can view the full version history of any page or article and restore any previous version at any time.
We need your input on these
?
How far back should version history go — should we keep all versions forever or is there a limit you would like?
?
Should changes made to page layouts also have their own version history, separate from the article content?
?
Should only Content Managers and Blog Editors be able to schedule content, or should Content Editors also have scheduling access?
Whenever content moves from one stage to another, the right person gets an automatic email. Reviewers know when something needs their attention. Authors know when their content has been approved, sent back, published, or taken down. No one needs to manually check — the right email goes to the right person at the right time.
Who gets notified and when
Submitted for review
Assigned reviewer gets an email with a direct link to the article
Sent to translation
Translator gets an email with a direct link to the content ready for translation
Sent back for changes
Author gets an email telling them their article needs changes
Approved
Author gets an email confirming approval and the scheduled go-live date if one is set
Published
Author gets an email with a link to their live article
Taken down
Author gets an email confirming their article has been removed from the site
We need your input on these
?
Should these notifications be email only or do you also want them sent to a Slack or Teams channel?
?
Should the email design use PADI's full brand look and feel or a simpler plain style since these are internal notifications?
?
Should notification emails go to a specific person or to anyone assigned to that role? For example, when content is submitted for review, should all Content Managers get notified or only the one assigned to that article?
Content Managers will be able to remove outdated articles from the site without permanently deleting them. Archived content disappears from the site and from Google search results, but stays in the system and can be brought back at any time. A content list view in Drupal will help editors identify what needs to be archived based on how old or inactive the content is.
How it works
1
A Content Manager opens the content list and filters for articles that have not been updated in a long time.
2
They select an article and archive it. It is immediately removed from the site and from Google search results — automatically, no extra steps needed.
3
The article is still in the system and can be restored at any time by moving it back to Draft.
4
If a scheduled end date was set, the article is taken down automatically on that date — no manual action needed.
We need your input on these
?
Who on the PADI team will be responsible for regularly reviewing and archiving outdated content after the site goes live?
?
Should the content list view be available to all editors or only to Content Managers?
?
What criteria should we use to identify content as ready for archiving — for example, not updated in 12 months, or no visits in the last 6 months?
When editors write content in Drupal, they use a text editor similar to a simple word processor. We are setting up two versions. Senior editors get access to all formatting tools. Everyone else gets a simpler version with basic options only. This ensures editors can only use formatting that works correctly on the live site.
Full editor
Content Manager and Administrator only
BoldItalicUnderlineHeadingsBullet and numbered listsLinksImagesTablesPull quotesVideo embedsUndo / Redo
Simple editor
All other roles
Plain text onlyNo formatting options
We need your input on these
?
When an editor copies text from Word or Google Docs and pastes it, should the original formatting carry over or should it paste as plain text?
?
Are there specific formatting options that certain roles need that are not listed above?
?
Should Blog Authors and Content Editors also have access to basic formatting like bold, italic, and links or should they be plain text only?
The new padi.com will support multiple languages. When a visitor goes to padi.com/de/ they see German content, padi.com/ja/ shows Japanese, and so on. If a page has not been translated into a language yet, the English version is shown automatically so visitors never see a blank or broken page.
Languages we are planning to support
English
padi.com/ (default)
German
padi.com/de/
Spanish
padi.com/es/
French
padi.com/fr/
Italian
padi.com/it/
Dutch
padi.com/nl/
Arabic
padi.com/ar/
Portuguese BR
padi.com/pt-br/
Thai
padi.com/th/
Simplified Chinese
padi.com/zh-hans/
Traditional Chinese
padi.com/zh-hant/
Japanese
padi.com/ja/
Korean
padi.com/ko/
What happens if a page is not yet translated
1
A visitor goes to padi.com/de/ but the page they are looking for has not been translated into German yet.
2
The English version is shown automatically. The visitor does not see a blank page or an error.
3
Once the German translation is published, the German version replaces the English fallback automatically.
We need your input on these
?
Is this the confirmed list of languages for launch or will some be added later?
?
Which content types will be translated at launch — all pages, or only certain sections like courses and blog articles?
?
For languages that are only partially translated at launch, is showing the English fallback acceptable or would you prefer those language versions to not be live until fully translated?
PADI uses Crowdin to manage translations. Once connected to the new site, the translation process becomes fully automated. When an English article is approved and ready, it is automatically sent to Crowdin for translation. When translators finish, the translated version comes straight back into Drupal and is ready for review — no manual exporting or importing needed.
How the translation pipeline works
1
A Content Manager approves an English article. It is automatically sent to Crowdin for translation into all active languages.
2
Translators in Crowdin see the article and can also see where each piece of text appears on the live site to make sure their translation is accurate in context.
3
When translation is complete, the translated version returns to Drupal automatically and sits in a Review state — it does not go live immediately.
4
A Content Manager or Translator reviews it in Drupal and publishes it. The translated version goes live on the relevant language page.
We need your input on these
?
Has PADI confirmed Crowdin licensing and can you share the API credentials so we can set up the connection?
?
PADI currently uses a custom Crowdin module. Has this been tested with the new Drupal 11 setup or will it need to be replaced?
?
Who on the PADI team manages the translators in Crowdin and assigns translation jobs?
?
Should all 13 languages be active in the translation pipeline from day one or should we start with a subset?
?
Once a translated article comes back into Drupal, who is responsible for reviewing and approving it before it goes live?