Great idea - regarding your second point, if you weren't aware there is a field called $ConflictItems which gets created sometimes in conflict documents (I think it's just for replication conflicts, not save conflicts) - as the name suggests, it lists all the items that caused the conflict.

@1 - $ConflictItems is only created for replication conflicts so it's of limited use. :-)

If IBM could just fix SPR # JRED7AWML6 this would be somewhat less of an issue.

Nick, I reported that and was told that it was something in my implementation! :-p

Regarding point 3), my idea { Link } might be helpful here.

@5 - No, it's nothing like that. The rules would be per-instance of replication or save conflict, not an attempt to aggregate them across multiple updates.

Even if the event were available, there would still be no appropriate language to write logic to handle it. LS is not a domain language like SQL that is suitable to write trigger logic about data manipulation. It would add overhead of executing some LS codes in such a backend event. And if errors or ui codes occur in the event handler, Notes has no proper way to report them and even roll back the affected document data. In my opinion, detecting & creating conflicts should be a optional feature rather than the default behavior. Other DBMS don't spend so much time on asking whether a record has been modified when saving it.

Starrow. The 'rules' suggestion could handle that without changing the default behaviour
Simply 'always accept newer' could be one rule, for example

@Christopher, As to rules, the replication conflicts handling options on the form properties box suffice for the case of replication if that feature is implemented precisely and without bugs. LS, Java & SSJS API of document.save() suffice for the back-end saving. Only two scenarios cannot be controlled. One is saving documents from client UI directly or uidoc.save(), the other is saving documents in the classic Notes web applications where even doc.save(true, false) is used, a save conflict will have been created before that call if the doc has been modified by others. So the sole missing piece is to make the current replication conflicts handling option work for save conflicts as well, after all the option reads "conflicts handling" not "replication conflicts handling". No else rule is needed.