SubscriptionData Column in Subscription table is null

[SaberRajabi1990]

Hi
In version 3.15.0, after I use the WaitFor command to suspend the workflow, a row is created in the [wfc].[Subscription] table, but the SubscriptionData column for that row is not populated and remains null.
This is my code:

public class HelloWorldWorkflow : IWorkflow
{
public string Id => "HelloWorldWorkflow";
public int Version => 1;
public void Build(IWorkflowBuilder builder)
{
builder
.StartWith()
.WaitFor("ManagerApproval", (data, context) => data.CorrelationID, data => DateTime.Now)
.Output(data => data.IsApproved, step => ((HelloWorldWorkFlowEventDataDto)step.EventData).IsApproved)
.Output(data => data.Value1, step => ((HelloWorldWorkFlowEventDataDto)step.EventData).Value1)
.Output(data => data.Value2, step => ((HelloWorldWorkFlowEventDataDto)step.EventData).Value2)
.If(data => data.IsApproved)
.Do(then => then
.StartWith()
.Input(step => step.Input1, data => data.Value1)
.Input(step => step.Input2, data => data.Value2)
.Output(data => data.Answer, step => step.Output)
)
.If(data => !data.IsApproved)
.Do(then => then
.StartWith());
}
}

[danielgerlag]

The subscription table is an internal concern, why do you want to read it?

[SaberRajabi1990]

What is the best way to pause a workflow for the approval of a specific user? Should I use Activity or WaitFor?

I want to get the list of events that the workflow is waiting for in order to present them as user tasks. Should I use the data from the ExecutionPointer table and the PersistenceData column, or the data from the Subscription table and the SubscriptionData column?
How can I store additional information such as the assigned user ID and the reason for stopping along with the Event?

Is the method _workflowHost.GetPendingActivity suitable, or should I use _persistenceProvider.GetSubscriptions?

I would appreciate your guidance.

[danielgerlag]

I would avoid coupling your code to the internal data store of workflow core, as it may change and break your app in the future. The API exposed by workflow host should be your best bet as we would always keep that backward compatible because it forms the contract with the user. You could store additional data in your own data store with a reference back to the workflow. If you are using WaitFor or Activity, then when you fire the event you can attach a data object, that will be persisted and passed to the workflow. See examples here:
Activity Worker
Event