Hi all - we’ve been evaluating the new publishing workflow and thought I could provide some feedback here. We love adding an option to specify groups who can edit, but can’t publish! More nuance among roles is really helpful.
Here are some things with testing that we are having to consider on how/if we implement this option in collections (3 main areas).
- Focus on drafts. In theory having these Authors who can’t publish work in drafts makes a lot of sense. But working in drafts as they currently exist could pose some hurdles:
- Since drafts don’t show the change history and/or allow a suggesting mode, it makes it very difficult for any Author who can publish to quickly see what they are approving. We would have to rely on Authors who can’t publish very clearly articulating the changes in inline comments or the publish message (which is behavior that is likely to not happen consistently.) Possible solution: Have a suggesting mode or a history of changes on the draft (it’s not lost on me that this is a big ask:)
- Since there is one-draft for every card, other Authors of either type can go in and make changes upon unpublished changes, and that could get confusing since they also don’t know what has changed. This is how the experience is now, but if we’re identifying new groups (Authors who can’t publish) outside the primary SMEs who already had an Author role, then it gets a bit riskier. Possible solution: If a draft were locked at the point that submitted a request to publish, that could be helpful?
- Notifications for drafts only happen once (normal function of drafts). Because these are essentially cards that need to move along the pipeline to get verified, it would be more ideal if these were ongoing and part of the digest so they don’t get overlooked. Possible solution: Having all drafts continue to notify via the digest might get noisy. Perhaps a different notification cadence for “locked up” publish requests?
- More/different distinction between what Authors can approve requests to publish. Possible solution: For our teams, it would be ideal if only the Verifiers on the card get notified about the request to publish or maybe if we could identify a specific group/s in the collection who get those notifications. A few reasons for this:
- If an Author who can publish isn’t part of the verifier group publishes the changes, it still has to move along to the verifiers to verify anyway. Why not just have this same group publish since we’ve already identified them to be keepers of the card.
- Authors who can publish, but who aren’t verifiers have to learn this new behavior/responsibility. Our verifiers are used to having to take action at the request of another, so I just wonder about the lift to train non-verifiers to assist with this. Plus now have more users getting noise with the notification.
- I think with our collections where our only authors are also verifiers in the collection, then nuance doesn’t really affect them (I actually think its our collections set up like this now that can find the most value in the new workflow because it’s allowing them to open up greater edit access while retaining some guardrails.)
- But for collections where we have a lot of Authors who aren’t verifiers, maybe less attractive. Here is one scenario. We have a Support collection, where we have about 50 employees who have access to Author, but only about 10 of those Authors are verifiers. To be able to have the rest of the company be Authors who can’t publish and only request edits is really attractive, but the 40 Support members are now getting notified on publish requests when I’d love if it were something my Verifiers were just having to handle.
- The new groups retain some powerful authors actions. We love that these new Authors who can’t publish can’t publish new cards either, but it looks like they can still create folders, move content around, manage card sharing settings, archive cards, etc. If we are identifying employees who we don’t want to publish in the collection, we likely also don’t want them to be able to do those “powerful” things either. Possible solution: Removing some access from the new Authors who can’t publish role?
Thanks for listening and for all the continued new changes that help us improve our experience for users.
cc:
Upvoted this post and wanted to note that we were just testing this out as well and the issue with not getting a notification for the publish request was big hindrance. This would require us to continually check drafts, and with how well the Task center works and notifications it would make since for publish request to live in there as they are items that need actioned on.
Upvoted as well, Though what I would really like to see is a form of Publishing workflow within each collection. For our company we like to keep our collections to a minimum and it would be nice to give a user their own *folder* within the collection that they have the permission to publish in without going through the workflow. Essentially granting them the permission owner of that singular folder within.
Say we have a collection called Projects and in that collection there’s a folder called Meetings and in that folder there’s a sub-folder called Bob’s Meetings & Recipes. Bob is not the owner of any collection, just a user, however we want to be able to give him the ability to publish ONLY in Bob’s Meetings & Recipes without being able to publish anywhere else and not create an entire collection just for that one user because Bob likes to publish a lot of burger recipes and has a lot of meetings; we want to give him a space for that.