Everyone says the same thing when a new CMS launches. “Just use Google Docs for drafting. Migrate the finished text. That’s how real teams work.” It sounds sensible. Separate the writing from the system. Avoid conflicts. Keep it simple.
That advice is wrong for EmDash.
The Google Docs workaround was a survival strategy for a CMS that couldn't handle real-time editing. EmDash was built without that limitation.
Not because Google Docs is bad — it’s excellent for documents. But EmDash was built for a different collaboration model entirely. The conventional wisdom assumes your CMS can’t handle multiple people editing the same content simultaneously without breaking things. WordPress can’t. Most traditional CMSs can’t. So the workaround became standard practice.
EmDash changes that assumption. Here’s why the old advice doesn’t apply, and how to actually collaborate on content in real time inside this new CMS.
What the “Google Docs First” Crowd Gets Right
Before I explain why it fails, let me acknowledge the logic. Google Docs handles concurrent editing smoothly. Multiple cursors. Real-time sync. No one overwrites anyone else’s work. You draft, revise, get approvals, then export to your CMS.
For WordPress, this workflow prevents disasters. Two editors hitting “Save” simultaneously on the same post creates a race condition. The last save wins. Content disappears. Hours of work lost.
So the advice made sense. For 2003-era architecture.
Where the Advice Breaks Down
EmDash runs on Cloudflare’s infrastructure with a fundamentally different content model. Content is stored as structured JSON — portable text — not as HTML blobs. The editing interface uses a block editor that tracks individual field changes, not whole-page saves.
This matters because:
- No save conflicts: EmDash saves field-level changes, not entire posts. Two editors can modify different blocks on the same page simultaneously without overwriting each other.
- Real-time presence: The editor shows who else is viewing or editing a piece of content — no more guessing if someone else is in there.
- Draft isolation: Unpublished changes live in a separate layer. You can preview draft content without affecting what’s live.
Google Docs still has its place. Long-form research. Policy documents. Anything that needs formal version history with comments. But for content that’s going straight into your site — blog posts, landing pages, product descriptions — the round-trip through Google Docs adds friction you don’t need.
How to Collaborate on Content in EmDash
Here’s the step-by-step workflow for a team of two or more editors working on the same site.
Step 1: Set Up User Roles
Before anyone edits anything, define who can do what. EmDash ships with role-based access out of the box: administrators, editors, authors, and contributors.
Expected outcome: Each team member sees only the actions they’re allowed to take. An author can write and submit for review but cannot publish. An editor can approve and schedule. This prevents accidental overwrites before you even start.
Go to the Users section in the admin panel. Invite team members by email. Assign roles. EmDash uses passkey authentication by default — no passwords to leak, no brute-force risk.
Step 2: Create Content with Ownership
When you create a new post or page, EmDash assigns ownership. The owner controls the content. Other users with appropriate permissions can edit, but the owner’s changes take priority in case of simultaneous saves on the same field.
Expected outcome: Clear accountability for each piece of content. If two editors modify the same field, the system doesn’t silently drop one person’s work — it flags the conflict.
This is the key difference from WordPress. In WordPress, two editors saving the same post causes a blind overwrite. In EmDash, field-level tracking means the system knows exactly what changed and by whom.
Step 3: Use Draft Mode for In-Progress Work
Never publish content that isn’t finished. EmDash keeps drafts separate from published content. You can have multiple drafts of the same post, each with different edits.
Expected outcome: An editor can work on a landing page while an author drafts a related blog post. Neither sees the other’s unfinished work unless they explicitly review the draft.
The preview system renders draft content on the front end without making it public. You get a live preview URL that only users with access can see. Share it with stakeholders for feedback without exposing anything to search engines.
Step 4: Edit Simultaneously — But Know the Limits
Here’s where EmDash differs from both Google Docs and WordPress. Open the same post in two browser tabs. Make changes in different blocks. Save in both tabs.
Expected outcome: Both saves succeed. Each block updates independently. No content loss.
Now try editing the same block — the same heading or paragraph — in both tabs simultaneously.
Expected outcome: The last save on that specific block wins. EmDash tracks block-level changes, not character-level changes like Google Docs. You won’t lose content in other blocks, but two people editing the same block at the same moment can still conflict.
This is the honest limitation. EmDash isn’t Google Docs. It doesn’t show multiple cursors or merge character-by-character edits. For block-level collaboration — which covers most real-world content workflows — it works fine. For two people trying to write the same sentence simultaneously, you still want a dedicated document editor.
Step 5: Use Revisions as a Safety Net
Every save creates a revision. You can compare any two revisions side by side. If someone makes a change you don’t agree with, roll back to the previous version.
Expected outcome: Full audit trail of who changed what and when. No more “who deleted the call-to-action section?” conversations.
Revisions in EmDash are per-content-item, not per-site. You get the granularity of WordPress revisions without the overhead of a full database backup every time someone clicks save.
Step 6: Leverage the Front-End Editor for Quick Fixes
EmDash includes a front-end editing mode. Navigate to any published page, click “Edit,” and modify content directly on the rendered page.
Expected outcome: A junior editor can fix a typo on a live page without navigating the admin panel. The change saves as a draft first — it doesn’t go live until explicitly published.
This reduces the friction of small edits. No need to open the admin, find the post, scroll to the right section. Click, edit, save, done.
Comparison: Collaboration Approaches Side by Side
| Feature | Google Docs + WordPress | EmDash Native | Notes |
|---|---|---|---|
| Concurrent editing | Full real-time in Docs, then manual migration to WordPress | Block-level concurrent saves in EmDash | Google Docs wins for character-level collaboration; EmDash wins for eliminating the migration step |
| Content loss risk | High during migration — copy-paste errors, formatting loss | Low — field-level saves prevent overwrites | EmDash’s structured content (portable text) preserves formatting automatically |
| Approval workflow | Separate — Docs for review, CMS for publishing | Built-in — roles, drafts, and revisions in one system | EmDash removes the “review in Docs, export to CMS” handoff entirely |
| Lock-in risk | Low — WordPress runs anywhere, Docs is separate | Moderate — full feature set requires Cloudflare Workers paid plan ($5/month) | Self-hosted EmDash loses sandbox plugin isolation |
| Learning curve | Low for Docs, moderate for WordPress admin | Moderate — familiar WordPress-like UI but new terminology | EmDash dashboard intentionally mirrors WordPress for muscle memory |
The Real Cost of the Google Docs Workaround
Every round-trip between Google Docs and your CMS costs time. The editor writes in Docs. The content manager copies to the CMS. Formatting breaks. Images need re-uploading. SEO metadata gets missed. Approvals happen in one system but publishing happens in another.
For a team publishing 5 posts per week, that’s easily 2-3 hours of overhead. For 20 posts per week, it’s a full day of busywork.
EmDash’s native collaboration eliminates that entirely. Write directly in the CMS. Review drafts in the CMS. Publish from the CMS. The metadata — SEO titles, descriptions, slugs, featured images — lives alongside the content, not in a separate spreadsheet.
When You Should Still Use Google Docs
Here’s where the conventional advice still holds.
Policy documents, legal copy, and anything requiring formal line-by-line approval with comments should stay in a dedicated document tool. EmDash’s editor doesn’t support inline comments or suggested changes. If your workflow requires three rounds of legal review with tracked changes, Google Docs (or a similar tool) is still the right choice.
Similarly, if your team includes non-technical stakeholders who need to review content but never touch the CMS, a shared document is simpler than giving them CMS access.
But for the actual content creation — writing, editing, optimizing, and publishing — the round-trip through Google Docs is an expensive habit, not a best practice.
One More Thing About How EmDash Changes Team Workflows
EmDash’s structured content model (portable text) means your content isn’t locked into HTML. The same JSON source renders to web pages, email newsletters, mobile apps, and API responses. This changes how teams think about content — not as a webpage you’re writing, but as a data entity you’re populating.
A product description written in EmDash doesn’t just appear on your site. It feeds your mobile app, your email campaigns, and your partner API. When the pricing team updates a field, every surface that consumes that field updates automatically.
That’s the real shift. Collaboration in EmDash isn’t just about avoiding save conflicts. It’s about building content that works everywhere, managed by a team that never needs to leave the CMS.
The Google Docs workaround was a survival strategy for a CMS that couldn’t handle real-time editing. EmDash was built without that limitation. Time to stop treating your CMS like a final destination and start treating it like the collaborative workspace it was designed to be.
- Why does the 'just use Google Docs' advice fail for EmDash?EmDash uses field-level saving and real-time presence, so multiple editors can work simultaneously without save conflicts. The Google Docs workaround is unnecessary.
- How does EmDash prevent save conflicts?EmDash saves changes at the field level, not the whole page. Two editors can modify different blocks on the same page without overwriting each other.
- What is the recommended workflow for team collaboration in EmDash?Set up user roles (administrator, editor, author, contributor) to define permissions. Then editors can write, submit for review, and publish without leaving the CMS.
