Do we need to create a temp/utility table (records) to hold the data temporally and commit at the end of the application process?
It does sound to me like this could be a case for using this approach. It works very well when you need to maintain tight control of the entry process.
With separation, all scripting should still take place in the UI (create layout based upon that data's table occurrence in your graph). You can change the layout ( Layouts > Layout Setup ) and uncheck 'Save Record Changes Automatically'. When asked, the User can say NO which reverts the record (and since it is new, it will not create it at all).
You can also place unspecified button or web viewer over your layout which stops record commit. Then place a SAVE button on the layout. When new record is created, save script would commit or issue a Revert Record/Request as needed.
Depending upon the data-entry layout itself, one technique or another would work best. If portals are involved, i.e., they create a new parent record and also add kids with 'Allow Creation' on a portal, prohibiting commit (and allowing Revert) will also revert changes to the kids although a transactional model (search google for 'Todd Geist Transactional') offers maximum protection in situations where the parent's total is depending upon the sum of kids and time-critical such as posting month-end for invoicing.
Overall, you can allow creation but either use layout setting or button to control if/when commit takes place. If you would like further clarification on anything mentioned, please let us know and we'll explain more thoroughly.
Thank you, keywords and LaRetta
We probably will go with the utility table and commit all the data during the last step. The volunteers will not have to worry about saving the data constantly throughout the process.