back and forth between two parties a couple times.

[Leslie Strom]

For a client, they want a two party contract, sender and recipient, and the ability for the recipient to review contract and modify it, then send it back to the sender who will sign it and then the recipient will sign it. They may want to be able to volley it more than once. I don't know how to make it an option for it to go back and forth.  Ideas?

[Open eSignForms]

There's currently no scheme to allow this. Ad hoc contracting is not the forte of OpenESF in which prepared transactions are created so they can be processed over and over in a reliable, tested fashion.  Ad hoc contracting has no such rigor.  Would currently recommend that the back-and-forth of preparing an agreement take place via something simple like email and when a finalized version is ready, have that go out for signature.

If you can show us any ideas of how your users would do this, please send them along as we can consider an enhancement to allow it.  The key is that most parties (outside of the users who belong to the company that operates OpenESF) are not trained in the software, so it must be easy for them to do the first time they see it.  It needs to take into account the back and forth works as how they suggest they are done and the back-and-forth updates are completed.

There has been a discussion for allowing a party to "reject" a document and send it back.  It may be possible this could work here, in which the sender sends to a recipient, and the recipient can then reject it back to the sender.  If the sender just completes the document, it would then go the the "sender signer" step and then the "recipient signer" steps (essentially four party steps: Sender Reviewer->Recipient Reviewer->Sender Signer->Recipient Signer.  Of course, this flow can be done now as long as there's no need for multiple back-and-forths.

[Open eSignForms]

One option would be to use the Activate Party feature (currently, it ignores if the party is already completed, but it could allow a completed party to be re-activated).

This would be "quick and easy" to do.  The downside would be how the party would perceived it.  You would have to include a checkbox or the like that party would use to say that the changes made need to be sent back for review, but the party would otherwise appear to complete the step normally.  Custom logic would then test the checkbox value, and if selected, it could reactivate the sending party.