6 Replies Latest reply on Oct 25, 2011 12:58 AM by Valery.Klimov

    Feature Discussion:  Customized Container Workflows

    Ryan Rutan

      Recently had discussions around this feature and wanted to share.


      Pretty simple, just as you have ""Environments" setup as a content-type, I think it would be worthwhile for SBS to have Workflows as a Content-Type.


      Some basic feature ideas to get it started would be:

      • As a container admin, I am able to create Workflows that anyone in the container can access
        • For example, I want to create a new document and I know I want it to go through a specific workflow, I should be able to do the follow
          • Select the workflow for the document to follow
        • Templatized workflow templates to start with, such as multi-stage approvals and rejections
          • Ability to create custom templates/steps to add to the mix as part of a plugin would be a home-run!
        • UI should be drag/drop intuitive
        • Workflows should allow groupings of people to be assigned
          • Perhaps this is an extension of a Project / Tasks, or the paradigm could be re-used/casted.
            • Projects can be used to create groupings of people in a container....and the workflow creates an anonymous task in that container


      Just some thoughts, but would like to see what you guys are thinking about in this field?

        • Re: Feature Discussion:  Customized Container Workflows



          I am not sure I understand the overall concept of a "workflow" in this description.  This sounds like some kind of combination between a content-type and a content-container.  Is this correct?


          Perhaps I could have a better understanding of this if you could describe a couple of use cases in which this would be helpful.




            • Re: Feature Discussion:  Customized Container Workflows
              Ryan Rutan

              So perhaps there's room for a smaller feature, where a user selects the people that need to approve this document (in order, or from a pre-saved (by container admin) container-level config) and then those people are notified of the pending approvals.  As the workflow proceeds.  For example, instead of choosing a single moderator for a "container"...being able to setup a moderator chain, where the chain is represented as a list of "groups of users" (perhaps friend-label like functionality)....and the document is published once all Users have given an approval?


              Taking a slight step back, if SBS was to be used to allow content to be created in a multi-step approval form...what is the solution Jive would recommend using the SBS vision/paradigm.  I think that might be the better question. For internal use-cases, i'd say this definitely falls within the platform realm of functionality for OOTB behavior...external implementations...it couldn't hurt, but no major use-cases.

                • Re: Feature Discussion:  Customized Container Workflows

                  Hey Rutan,


                  I have filed a feature request for group moderation: the ability to require multiple people to need to approve one piece of content.  The request id is CS-17635.




                    • Re: Feature Discussion:  Customized Container Workflows
                      Ryan Rutan



                      Some amendments that might be worth noting:


                      The product already allows "multi-person" approval for documents...what I'm asking for is the ability to have variations.

                      • For instance, OOTB the multiple approvals "workflow" is setup such that all approvals are attained in a single-step workflow.  There is no order required. 
                        • In a 3 approver, approver 1 can rejects, approver 2 can approves, and approver 3 approves...now, all 3 of them are made aware 2x over when the document is amended and resubmitted for approval.  Rather than Approver 1, upon approval then Approver 2 is notified, etc...
                        • I'm not saying that this has to be THE WAY, because I like the organic approval model; however, it would be ideal if there were options available.
                      • Once you make options available, it becomes an issue on how to manage them.  What I am asking for may be best summarized, buy the Collaboration options on definition for defining approvers.  Instead of having to list all of the approvals each time; wouldn't it be nice to select a "templated" workflow object...that has a name, description and meaning that the user defines that makes sense to them.
                        • They could create a workflow that is just like OOTB, but has 6 names pre-selected
                        • They could create a workflow that is multi-stage
                        • They could create a workflow that uses "user groupings" instead of users for workflow, where all or some of the approvals are required.
                          • For example, what if I only want 1 approver for a list of approvers to have to approve it....but it can be any of them.
                          • Right now, I do not see a way to achieve this in the product.
                        • All of these use-cases would be represented as an option in the UI under Manage Collaboration section, to say
                          • Create Ad-Hoc Approval => Current OOTB experience
                          • or select from a pre-defined Approval process defined in that container or by the user.

                        So what I'm asking for are options to the Manage Collaboration feature...and providing a recommendation on how to manage/convey those options...as long as the user has options to do the above...and can self manage those options...that is the core of what I am asking.


                        Having just read this, I'm not sure "multiple approvers" as a core issue will do this request the proper attention I think it needs.  Lastly, could you confirm that the ticket has been updated?  thanks again Cory. =)

                          • Re: Feature Discussion:  Customized Container Workflows

                            Hi Ryan,


                            This is very similar to the details that I noted in the feature request.  However, I have added the your full description to the bug.




                              • Re: Feature Discussion:  Customized Container Workflows

                                Hi there,

                                my 5 cents on this point

                                1. task object should be enabled for social groups, spaces and other locations of Jive documents live where instead of projects Jive supports for now.

                                2. Workflow templates might be assigned for specific document category/tag by default

                                3. Workflow map creator should be able to specify (workflow map level)

                                3.1 map collaboration rules (like for documents) - who (people, groups, org.chat) can use, edit workflow, change assignee/deadline, suspend/resume document processing

                                3.2 Initiator and performers of each step shall be as workflow participants

                                4. Workflow designer should be able to specify for Initiator the following abilities:

                                4.1 If Initiator can change performers and deadline, suspend/resume document processing, if Initiator is a final approver for a document.

                                4.2 If performer can reject document to specific step or to originator, re-route it to other people (ad hoc workflow)

                                5. Workflow designer should be able to use org chat for escalation, re-route functionality

                                6. For parallel processing steps might be specified the mode of their processing

                                6.1 Wait for first task (first completed task completes all the parallel tasks as well - job does not wait others ones completion)

                                6.2 wait all the tasks - job will not go to the next step until all the parallel steps will be completed

                                7. if step if assigned to group (not specific user), then the following ability should be supported

                                7.1 assign to the all members

                                7.2 assign to group coordinator (for the next re-route)

                                7.3. member can take the task (all the members will see the task queue and anyone of them can take it for execution - after that he/she will be assigned to the tasks as performer. For this mode the feature "Return to queue" will be supported as well - it allows to return the tasks to queue in order to another user will be able to execute the task)


                                Feel free to contact me via e-mail valery.klimov@ecm-consulting.ru