Question: I'm curious what the design argument for `doParallel:::doParallelSNOW()` giving a warning when globals are explicitly specified in `.export` could be? For example,

```
library("doParallel")
registerDoParallel(cl <- parallel::makeCluster(2L))

a <- 1
y <- foreach(i = 1L, .export = "a") %dopar% { 2 * a }
## Warning in e$fun(obj, substitute(ex), parent.frame(), e$data) :
##  already exporting variable(s): a

```

Is it possible to disable above warnings in doParallel?

I'd argue that such a warning would suggest the user/developer *not* to specify `.export` and rely fully on foreach adaptors to take care of globals. However, the success of identification of globals differ among adaptors.

Package versions: doParallel 1.0.11, iterators 1.0.9, foreach 1.4.4

**CLARIFICATION 2018-01-14**: [These warnings occur after doParallel first having identified globals automatically and then appending the ones the developer list in `.export`](https://github.com/cran/doParallel/blob/b843662b9c49fb610434ae22713fbc188a06b1c3/R/doParallel.R#L414-L434) - my question is on why it doesn't not accept the deliberate choice that was done by the developer? Warning about correct globals is a bit misleading.

Answer: 
So it turns out that the solution to this question requires a bit of scripting using `groovy`.

Below is the updated process model diagram, in it I start a new instance of the `Complete Task` process using a script task then if the user wishes to add more tasks the exclusive gateway can return the user to the Create task (user task) **OR** finish the process. 

I clear down any values in the fields held within the user task within the script task before I pass the scope back to the user task.

[![Update Process](https://i.stack.imgur.com/yV5m7.png)](https://i.stack.imgur.com/yV5m7.png)

The image below shows my *Complete Task* process that gets called by the main process using a script

[![Complete Task](https://i.stack.imgur.com/oo51d.png)](https://i.stack.imgur.com/oo51d.png)

Here I avoid using `parallel gateways` in preference of creating a new instance of the *Create Task* (user task) and a new instance of the *Complete task* process (not subprocess) via means of the script.

To start a new instance of the Complete Task process we have to start the process using the function `startProcessInstanceByKeyAndTenantId()` under a `runtimeService` instance for the process, although I could also use `startProcessInstanceByIdAndTenantId()`:

```
//Import required libraries
import org.activiti.engine.RuntimeService;
import org.activiti.engine.runtime.ProcessInstance;

//instantiate RunTimeService instance
RuntimeService runtimeService = execution.getEngineServices().getRuntimeService();

//get tenant id
String tenantId = execution.getTenantId(); 

//variables Map
Map<String, Object> variables = runtimeService.getVariablesLocal(execution.getProcessInstanceId());

//start process (processId, variables, tenantId)
ProcessInstance completeTask = runtimeService.startProcessInstanceByKeyAndTenantId("CompleteTask", variables, tenantId);

//Clear variables to create a fresh task
execution.setVariable("title", "");
execution.setVariable("details", "");

```

Using this approach I avoid creating multiple subprocesses from the parent process and instead create multiple processes that run separate from the parent process. This benefits me as if the parent process completes the others continue to run.
1. Seems like you are updating only one variable (or a single set of variables) as a result of each task. This will override the previous value. use distinct variables, or append something before each variable to mark it unique for the task/ sub-process completed. see [collapsed sub-process](https://www.activiti.org/userguide/#bpmnSubProcess)
2. Yes, each sub process gets its own unique execution id, But the main execution ID or process instance ID remains same