The default cancel button of the client always calls rollback. So, you should always use rollback to copy this behavior. The behavior of rollback is two-fold:

• If the object is new (i.e. created and not committed yet) it will be removed.
• If the object is not new the uncommitted changes will be rolled back.

As Jasper pointed out, when you use an invoke button pointing to a microflow to act as a new button it depends on the actions performed in that microflow whether you have to use rollback or delete.

• If this microflow only creates the object and doesn't commit the object it is sufficient to use a rollback.
• But if it also commits the object you should remove the object instead of just calling a rollback. Rollback will not remove the object because it isn't 'new' anymore after the first commit.

It depends on what you are trying to simulate. If it is a action where you want to edit some existing objects and then you want to cancel you should rollback. Of course you don't want to delete an object that you are editing if you click the cancel butten.

But when you use an invoke button to act as a new button it depends on the actions performed in the microflow. If the invoke action only creates the object and won't commit the object shown in the dataview it is sufficient to use a rollback. But if you have committed the object in your initial microflow you should remove the object instead of just calling a rollback.