The purpose of the Windows workflow transaction services (WorkflowCommitWorkBatchService) is to enable custom logic regarding the commitment of work batches (also known as PersistencePoints). When a work batch is committed, the runtime calls into the current transaction service and passes a delegate to call to do the actual committing of the work batch. The runtime still must do the commit, but letting a service insert itself into the process enables some customization around the commit process.
The WF framework does not support the ability to bring your own transaction from the outside into a workflow instance. The only types of ambient transactions supported by the WorkflowCommitWorkBatchService are transactions that are originated by the workflow instance. Ambient transactions that are originated by the host application executing the workflow runtime are temporarily removed from the current thread to reduce their side effects. After the workflow is idle, the host application original ambient transaction contained by is placed back in the thread.
The WF runtime engine requires a workflow transaction service. By default, it uses the DefaultWorkflowCommitWorkBatchService. The host application can choose to replace the DefaultWorkflowSchedulerService with SharedConnectionDefaultWorkflowCommitWorkBatchService or with a custom service.