Publishing Workflow Feature Requests

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).

1. 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:
   1. 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:)
   2. 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?
   3. 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?
2. 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:
   1. 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.
   2. 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.
   3. 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.)
   4. 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.
3. 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: @Matt Garren