You are obtaining a license to utilize the process application which means one or more applications used to track items through workflow processes, and can include one or more orchestrations that provide the logic for the invocation of Web services (“Plugins”).

You can’t give away or resell the Process Application.

Use of the Process Application is limited to the number of SBM licenses you purchased from Serena.

The Process Application is provided without any guarantee that it will work in your environment.

We don’t provide technical support for the Process Application.

The full details of the End User License Agreement follow, and you should read them.

READ THIS END USER LICENSE AGREEMENT ("AGREEMENT") CAREFULLY. BY DOWNLOADING, OR OTHERWISE INSTALLING OR USING THE PROCESS APPLICATION, YOU AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO THESE TERMS AND CONDITIONS, DO NOT USE THE PROCESS APPLICATION.

We grant You a perpetual, non-exclusive, non-transferable license to use and modify the Process Application within the Territory, in accordance with any applicable User Documentation, up to the Licensed Capacity, subject to this Agreement.We grant You a license to perform and deploy the Process Application solely as incorporated within Our software product known as Serena Business Manager, and solely for Your internal business operations. You may not sell, rent, lease, or otherwise distribute or disclose the Process Application or any modification to any third party. To the extent that You modify the Process Application or create a derivative work of it, We grant You a non-exclusive, non-transferable license to use such modification or derivative work at no additional charge, subject to such limitations in this Agreement. You may not permit any third party to use or access the Process Application and/or User Documentation. We have no obligation to provide You maintenance or support on the Process Application. Software provided by third party vendors ("Third Party Software") may be embedded in or delivered with the Process Application. The terms of this Agreement and any other terms that We may specify will apply to such Third Party Software. You may only use the Third Party Software with the Process Application, and You may not use the Third Party Software on a stand-alone basis or use or integrate it with any other software or device.

We retain all right, title and interest in and to the Process Application and User Documentation and all copies, improvements, enhancements, modifications, and derivative works thereto. You will not disassemble, decompile, or reverse engineer the Process Application. Except as otherwise provided, We do not grant You any express or implied rights under this license to any of Our patents, copyrights, trade secrets, trademarks or other intellectual property rights.

“Licensed Capacity” means the number of Serena Business Manager (“SBM”) Named User and/or Seat licenses you have purchased from Serena.

"Process Application" means one or more applications used to track items through workflow processes, and can include one or more orchestrations that provide the logic for the invocation of Web services, in object code form.

"Territory" means the country of Your principal place of business.

"User Documentation" means any user guides, installation guides, and documentation that may be provided with the Process Application and/or available on Our website.

"We," "Our," and "Us" means Serena Software, Inc.

"You" and "Your" means the individual or company who is licensed to use the Process Application in accordance with the terms and conditions of this Agreement.

THE PROCESS APPLICATION IS PROVIDED "AS IS." WE DISCLAIM ANY AND ALL WARRANTIES, INCLUDING ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND STATUTORY WARRANTIES OF NON-INFRINGEMENT.

IN NO EVENT WILL WE BE LIABLE TO YOU FOR (A) ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR (B) LOSS OF DATA, LOSS OF PROFITS, BUSINESS INTERRUPTION, OR SIMILAR DAMAGES OR LOSS, EVEN IF WE HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. EXCEPT AS LIMITED BY APPLICABLE LAW, AND REGARDLESS OF THE BASIS FOR YOUR CLAIM, OUR MAXIMUM LIABILITY UNDER THIS AGREEMENT WILL BE TEN DOLLARS ($10). THE FOREGOING LIMITATIONS WILL APPLY NOTWITHSTANDING THE FAILURE OF THE ESSENTIAL PURPOSE OF ANY LIMITED REMEDY.

Upon any termination, You shall immediately discontinue use of the Process Application and uninstall and destroy all copies of the Process Application. We may discontinue offering the Process Application at any time.

This Agreement constitutes the entire agreement between Us and You relating to the Process Application and may not be modified unless in a writing signed by both You and Us. If any provision of this Agreement is held to be illegal or otherwise unenforceable by a court, that provision will be severed and the remainder of the Agreement will remain in full force and effect. The waiver of any right or election of any remedy in one instance will not affect any rights or remedies in another instance. The Process Application and User Documentation are subject to United States export controls under the U. S. Export Administration Act, including the Export Administration Regulations, 15 C.F.R. Parts 730 et seq. (collectively, "Export Control Laws"). You agree to comply with all Export Control Laws. The Process Application and User Documentation are deemed to be "commercial computer software" and "commercial computer software documentation" as defined in FAR Section 12.212 and DFARS Section 227.7202, as applicable. Any use, modification, reproduction, release, performance, display, or disclosure of the Process Application and User Documentation by the U.S. government will be solely in accordance with the terms of this Agreement. This Agreement will be governed by the laws of California, U.S.A. Any suits related to this Agreement shall be brought in the federal courts for the Northern District of California or the state courts in Santa Clara County, California. The United Nations Convention on Contracts for the International Sale of Goods and the Uniform Computer Information Transactions Act, as adopted or amended from time to time, do not apply to this Agreement or the Process Application.

I Agree & Download

Multiple Approvers Demo AppHot

Multiple approvals possible in one state will speed up your approvals processes. Often there is no need to wait until one individual approves an item before another individual can do the same. These processes can also work in any other situations where concurrent work can be performed. For example, in a new product onboarding process one individual may be able to enter tech specs on the item within the process while someone else writes the description.

Drawbacks: Each step must be completed before the next, one could be delayed days as one person is out of office, then by the time the next person gets it they may be out or busy themselves. This can cause approvals to be painfully slow.

Subtask Approvals

Benefits: Flexible, different count of users per item as desired. All approvers can be working on the items at once.

Drawbacks: Denials and re-submittals are more difficult. Many items created simply to approve one. Notes added on approvals will not show on parent item. Individuals may need to add notes or fill fields in multiple items making privileges awkward, or complicated scripts must be written.

Most of the benefits in this case can be achieved with one of the two last methods without the drawbacks or many additional items in the database.

Fields:

Each Subtask will have an approver field.

Actions:

Action to move primary item from holding state once all subtasks are completed.

Binary Multi Approvals

Benefits: Fast, transparent, One click, can be used with transitions from notifications.

Drawbacks: Limited by users in fields, 2 fields needed per approval user which makes large numbers difficult. Best for situations where the same few user fields need to approve each item.

Description: Each approval needed will require a binary field defaulted to “no” on submit and a user field. Then a transition is made for each user field binary field pair. The transition should be restricted by to only the user in that field (field in current user) and the binary is set to no. They should be quick transitions. On the transition the binary field is set to “yes”. On the approvals state a button is added to the form for each transition and mapped to them. A click by that user therefor sets their binary field to “yes” and the transition button disappears while no form is shown.

Each of these transitions simply goes to the same transition, where if all binaries are set to “yes” then the item is moved forward in the workflow, if some nos remain as more approvals are required the otherwise rule sends the item back to the approvals state.

A transition to a state where the submitter is the owner can be added in case someone wants to deny the approval, and a transition to that state added from the approvals state. Remember to set the binary fields back to “no” on this transition so all users can re-approve the edited item once it is re-submitted for approval. This is another way to cut down on needless items in the database.

For an example of a fully featured version of this see the scrum team approvals app also available for download.

Components:

Fields:

ApprovedBy1: set to no on submit, set to yes when approver one selects their approval transition, set to no on any transition declining.

ApprovedBy2: same as above for Approver2

ApprovedBy3: same as above for Approver3

Approver1: set to user who will be approving, related to ApprovedBy1, their approve transition restricted by user in this field and ApprovedBy1 being in the no selection.

Approver2: same as above, related to ApprovedBy2

Approver3: same as above, related to ApprovedBy3

Decision:

Branch rule, if ApprovedBy1, ApprovedBy2, and ApprovedBy3 are all set to Yes, the item moves through to the approved sate, if not it returns to the approvals state to wait the additional needed approvals.

Form/Transition overrides:

Transitions added to form and mapped to appropriate transition in line with the fields. Restrict by rule added to each transition so approval is only available if the user is in the associated approval field and the binary field associated with same is marked as not yet approved. Transitions for each into the decision state should be quick transitions. Each transition for each approval sets the matching binary field to approved/yes.

Javascript Multi Approvals

Benefits: Flexible user count (E.G. one approval item could have 2 users, the next one 8). Easy to implement. Easy graphical view of progress. Able to set a threshold (E.G. 3 of any of these users must approve/ 75% of these users must approve)

Description: All users that need to approve an item are added to one field, this field is copied to a yet to be approved field which is used to drive the process. As these users approve the item their name is subtracted from the field, and the field goes through a decision that simply checks if there are any users left in the field. If there are not, the item is transitioned to approved, if there are, it goes back to the approval state to await the additional approvals.

The count threshold version instead of checking whether the field is empty or not on the decision checks if the binary field named threshold is set to yes (it is defaulted to no). The approval form checks if the number of original possible approvers minus how many are yet to approve is equal to or greater than the number of required approvals you have set in the javascript. In this case care must be taken to make sure it is only used in a process where at least this number of approvers will be entered in the field on any given item.

The percentage threshold version instead of checking whether the field is empty or not on the decision also checks the threshold binary field on the decision as above. In this case the binary is set via javascript to yes when the number of people who have approved divided by the number originally available to approve is higher than the percentage set in the javascript (via decimal rather than percent, E.G. “.75” rather than 75%. In this case care must be taken to make sure that the percentage used makes sense with the number of users expected to be entered, for example 90% of 4 users is all 4.

This workflow has a progress bar in each case showing % of the total approvals needed to move forward has been achieved.

A final version which is a yes/no etc. voting application with pie chart is available in the subtaskless voting app also available for download.

Similarly to the binary approvals app you can add a transition that denies the approval, sending the item back to a state where the submitter owns it to re-work and re-submit it for approval. In this case the javascript on the submit that copies the original approvers user field to the yet to approve user field should be run so the approvals restart once they re-submit. This saves on items in the database instead of creating a new item each time.

Components:

Fields:

Approvers Required Field: Holds all those who will need to approve the item, or in the case of threshold or percentage approved, the total pool of users who could approve. Could be defaulted, filled, or set to be a few other user fields added together.

Approvers Not Yet Approved Field: Holds a copy of the Approvers field, subtracted from one by one as users approve the item, they are removed from the field.

Threshold Field: Binary field set to no on submit. Used only in the percentage and count versions it is set to yes on the approval that sends the item over the percentage or count threshold.

Decision:

Checks if anyone is left on the Approvers Not Yet Approved field, and if there are sends it back to the waiting approvals state, if not, the item moves into the workflow as approved. In the case of the threshold by count or percentage versions this instead checks whether the binary field “Threshold” has been set to yes by the javascript.

Javascripts:

In the forms for each type of java script multi-approvals are the javascripts needed as form actions. Percentage of and count of have numbers that can be changed depending on the desired threshold. The 0.75 in percentage of, for example, represents 75% approval. In the count of version the variable number is the 3.

Form:

The form must have the fields called by the javascripts as shown in the example process app. Some are hidden on form load, and shown then written to on form submit.