Permissibility of Database Changes for Start, Resume, TimedTrigger, and Notification Service 
In general, the database may only be changed if ensured that the action was carried out by the user and not “foisted” onto the user. A method for "foisting" requests is referred to as Cross Site Request Forgery (XSRF).
Due to the architecture of the World Wide Web, it is not possible to determine whether a start request or resume request for an application originated from a user and not from an XSRF attack. For this reason, the application may not change the state of the server during this request.
This also applies to actions triggered by the TimedTrigger and notification service if the TimedTrigger or notification service is not activated by a user action but immediately when the application starts or resumes.
Example
The workflow for approving leave sends e-mails to managers with a link for approving leave. The leave must not be approved directly upon clicking the link. The application can be secured whereby only a form with the information for approving leave is displayed when the application is started and the user is able to choose either the Approve button and also a Cancel button if possible. The leave is not actually approved until the Approve button is clicked.
All actions executed by the user are protected against XSRF by the Web Dynpro Framework. This means it is not possible to foist the button click onto the user.