anchor.diff:  
   The following applies for transient variables:
   
  -* There is not history stored at all for transient variables.
  -* Like _regular_ variables, transient variables are put on the _highest parent_ when set. This means that when setting a variable on an execution, the transient variable is actually stored on the process instance execution. Like regular variables, a _local_ variant exist of the method if the variable should be set on the specific execution or task.
  +* There is no history stored at all for transient variables.
  +* Like _regular_ variables, transient variables are put on the _highest parent_ when set. This means that when setting a variable on an execution, the transient variable is actually stored on the process instance execution. Like regular variables, a _local_ variant of the method exists if the variable should be set on the specific execution or task.
   * A transient variable can only be accessed until the next 'wait state' in the process definition. After that, they are gone. The wait state means here the point in the process instance where it is persisted to the data store. Note that an _async_ activity also is a 'wait state' in this definition!
  -* Transient variables can only be set by the _setTransientVariable(name, value)_, but transient variables are also returned when calling _getVariable(name)_ (a _getTransientVariable(name)_ also exists, that only checks the transient variables). The reason for this is to make the writing of expressions as easy and existing logic using variables works for both types.
  -* A transient variable _shadows_ a persistent variable with the same name. This means that when both a persistent and transient variable is set on a process instance and the _getVariable("someVariable")_ is used, the transient variable value will be returned .
  -
  -Transient variables can be get and/or set in most places where regular variables are exposed:
  +* Transient variables can only be set by the _setTransientVariable(name, value)_, but transient variables are also returned when calling _getVariable(name)_ (a _getTransientVariable(name)_ also exists, that only checks the transient variables). The reason for this is to make the writing of expressions easy and existing logic using variables works for both types.
  +* A transient variable _shadows_ a persistent variable with the same name. This means that when both a persistent and transient variable is set on a process instance and the _getVariable("someVariable")_ is used, the transient variable value will be returned.
  +
  +Transient variables can be got and/or set in most places where regular variables are exposed:
   
   * On _DelegateExecution_ in _JavaDelegate_ implementations
  -* On _DelegateExecution_ in _ExecutionListener_ implementations and on _DelegateTask_ on _TaskListener_ implementations.
  +* On _DelegateExecution_ in _ExecutionListener_ implementations and on _DelegateTask_ on _TaskListener_ implementations
   * In script task via the _execution_ object
   * When starting a process instance via the runtime service
   * When completing a task
  
positive.code: 
  image::images/api.transient.variable.example.png[align="center"]
  
  Let's assume the 'Fetch Data' service task calls some remote service (for example using REST). Let's assume some config parameters are needed and need to be provided when starting the process instance. Also, these config parameters are not important for historical audit purposes, so we pass them as transient variables:
  
  [source,java,linenums]
  ----
  
negative.code:        .start();
  ----
  
  Note that the variables will be available until the user task is reached and persisted to the database. For example, in the 'Additional Work' user task they are not available anymore. Also note that if 'Fetch Data' would have been asynchronous, they won't be available after that step too.
  
  The 'Fetch Data' (simplified) could be something like
  
  