anchor.diff:  			flowable:assignee="#{authorizingManager.account.username}" />
   ----
   
  -Where "authorizingManager" could be a bean provided by a producer method:
  +Where +authorizingManager+ could be a bean provided by a producer method:
   
   [source,java,linenums]
   ----
  
positive.code: }
  ----
  
  The ++@CompleteTask++ annotation offers the possibility to end the current conversation. The  default behavior is to end the conversation after the call to Flowable returns. Ending the conversation can be disabled,  as shown in the example above.
  
  
  ==== Referencing Beans from the Process
  
negative.code: <!-- list the processes to be deployed -->
  <processes>
  	<process resource="diagrams/myProcess.bpmn20.xml" />
  	<process resource="diagrams/myOtherProcess.bpmn20.xml" />
  </processes> 
  ----
  
       
  === Contextual Process Execution with CDI
  
  In this section we briefly look at the contextual process execution model used by the Flowable CDI extension. A BPMN business process is typically a long-running interaction, comprised of both user and system tasks. At runtime, a process is split-up into a set of individual units of work, performed by users and/or application logic. In flowable-cdi, a process instance can be associated with a CDI scope, the association representing a unit of work. This is particularly useful, if a unit of work is complex, for instance if the implementation of a user task is a complex sequence of different forms and "non-process-scoped" state needs to be kept during this interaction.
  
  In the default configuration, process instances are associated with the "broadest" active scope, starting with the conversation and falling back to the request if the conversation context is not active.	 
  
  ==== Associating a Conversation with a Process Instance 
  	
  When resolving @BusinessProcessScoped beans, or injecting process variables, we rely on an existing association between an active CDI scope and a process instance. flowable-cdi provides the +org.flowable.cdi.BusinessProcess+ bean for controlling the association, most prominently:
  		
  * The _startProcessBy(...)_ methods, mirroring the respective methods exposed by the Flowable +RuntimeService+ allowing to start and subsequently associating a business process.
  * +resumeProcessById(String processInstanceId)+, allowing to associate the process instance with the provided id.
  * +resumeTaskById(String taskId)+, allowing to associate the task with the provided id (and by extension, the corresponding process instance).
  
  Once a unit of work (for example a user task) is completed, the +completeTask()+ method can be called to disassociate the conversation/request from the process instance. This signals the engine that the current task is completed and makes the process instance proceed.
  
  Note that the +BusinessProcess+ bean is a ++@Named++ bean, which means that the exposed methods can be invoked using expression language, for example from a JSF page. The following JSF2 snippet begins a new conversation and associates it with a user task instance, the id of which is passed as a request parameter (e.g. ++pageName.jsf?taskId=XX++):
  
  [source,xml,linenums]
  ----
  <f:metadata>
  	<f:viewParam name="taskId" />
  	<f:event type="preRenderView" listener="#{businessProcess.startTask(taskId, true)}" />
  </f:metadata>
  ----
  
  ==== Declaratively controlling the Process
  
  Flowable-cdi allows declaratively starting process instances and completing tasks using annotations. The ++@org.flowable.cdi.annotation.StartProcess++ annotation allows to start a process instance either by "key" or by "name". Note that the process instance is started _after_ the annotated method returns. Example:
  		
  [source,java,linenums]
  ----
  