Someone request something, a set of approvers mused about it and the result has consequences. We all have build this type of applications in eMail, Notes, Sharepoint, dbBase, using spreadsheets, paper forms or high powered BPMN/BPML/BPEL engines. Workflow engines are supposed to ease the creation of the forms flowing through the process. They follow the same pattern: user fills in the form, some routing magic happens, the approver sees the same form, but with approve/reject and eventually a comment etc. We record who and when the approval happened (even using a signed section in Notes client apps) and the routing (and notification) magic kicks in again.
Since our systems are well designed and secure this works very well. Does it?
When we only record the who and when of approvals, but not the what, we open the door to the challenge:"I never approved THAT". So we need to capture a snapshot of how the record looked like at the moment of approval. Ideally that snapshot gets secured with a digital signature leading to non-repudiation. Now the next approver needs to not only endorse the data snapshot at the time of approval, but also the previous signature, so it can't be retracted either.
Now try to model that in an RDBMS (let me know if you succeed). This is one of the reasons why workflows are document oriented (sure you can persist it into an RDBMS, but you need to reassemble it to validate the signatures) and will stay that for the foreseeable future. The current "gold standard" for document signatures is XML Signature with an JSON equivalent in the making.
Some applications have support for signatures build in. For others we need to have a look at code. Stay tuned.
Update/Bonus challenge: Make the non-repudiation external verifiable (e.g. submit that to the court evidence collection). Hint: it is in the data, not the application