Can I invite other community members to collaborate on an article?

LisaM 

Good question, and unfortunately the short answer is no — this isn't something the Articles app supports out of the box, at least based on what we've seen across implementations.

Permissions in Articles are scoped at the collection level, not the individual article level, so there's no native way to grant edit rights to specific members on a single article while keeping the rest of the collection's default permissions intact. The platform just doesn't have a per-article permissions layer — it's collection or nothing.

The workarounds that exist (separate collections per article with tailored permissions) are exactly the kind of manual, hard-to-scale approach you're trying to avoid, and they get unwieldy fast once you're dealing with more than a handful of articles or contributors.

Happy to dig further if you want to explore or talk through what a collection-splitting workaround would actually look like in practice.

That wouldn't work for us at all Sara as potentially we'll have over 120 article collections that would all need specific permissions along with over 120 different 'roles' that would need to be created to accommodate the volunteer groups and then adding the specific individuals into those roles again would have to be a manual process where it gets super unwieldy! 

I think we'll have to go down the route of only one volunteer being responsible for updating their strategy plan throughout the year if we were to use the articles app. The only other option is for them to constantly upload a new and updated document in a files gallery but even that then gets super complicated and confusing. 

It's a real shame that we cant do an 'invite to collaborate' type feature for the articles as that would be really useful.  

I have a similar question, although I am not looking for working on an article simultaniously or be able to collaborate on an article, mostly on a blog post or uploaded word doc. 

I was wondering if - apart from the workaround in articles - there are other options to collaborate on a document or content on the community AND manage versions and the same time. How does version management look if you are working on the same documents/wiki/content at the same time?

Thanks!

Sara Collins would you have any recommendation for this? Thank you in advance! 

Hi Irene van der Zanden 

I hope you're doing well, and thank you for tagging me! Here's how I'd approach this on 13.x:

1. Use a "working" article collection to draft, then move the final version
Rather than creating a collection per article (which, as Lisa mentioned, doesn't scale), you can set up just two:

• A restricted "working" collection that only the people collaborating on content have permission to create and edit in.
• Your open, published collection that the wider group sees.

Authors can create their article in the working collection and either save it as a draft or post it there. Either way it stays tucked away from the broader group while the collaborators review and edit it. Once edits are done, an admin can move the finalized article into the open collection. That way you only need one extra collection and one role, instead of setting up permissions for every article.

The one trade-off is that anyone permissioned to the working collection can work on everything in it. It's not a per-article "invite to collaborate," but for most teams that's a manageable group.

2. Version management is built into Articles
This is where Articles works really well for collaboration. Every article keeps a version history, so as different people make edits you can see how the article has changed over time. You can also compare versions against one another to see exactly what changed, and restore a previous version if something needs to be rolled back. So even with several people working on the same article, nothing gets lost.

3. For Word documents, keep the working copy outside the gallery
Media galleries let you edit a file and replace the uploaded document, but they don't keep a version history, so each upload overwrites the previous one. If the team needs to co-author a Word doc, I'd recommend keeping the working copy in SharePoint/OneDrive (where co-authoring and version history are built in) and linking to it from the group. Then upload only finalized versions to the gallery, with the version or date in the title (e.g., "Strategy Plan v2 – Oct 2026"). Or, if the content doesn't need to stay a Word doc, moving it into an article gives you the version history right in the community!

So in short: draft and edit in a restricted working collection, use article version history to compare and restore changes, then move the final article to the open collection. Keep SharePoint/OneDrive for anything that needs to stay a Word doc.