The new workflow instance should resume execution from the exact state where the last one left off

Community Support
,
1

Hi,
I am looking for advice on managing a use case where we need to terminate an existing workflow instance and start a new one while restoring the state up to a specific restore point. The key requirement is that the new workflow instance should resume execution from the exact state where the last one left off.

Here’s the scenario:

  • A user goes through an onboarding process with multiple steps.
  • At each step, they receive a session code.
  • If the user exits and returns later, they should be able to resume the onboarding process using their session code, even if the original workflow instance has been terminated.
2

Don’t terminate the workflow execution while the user can come back.

3

Hello. thanks for reply. we have to terminate workflows for GDPR reasons. We plan to store progress outside so users can continue where they left off using a session code. Open to suggestions if you have a better approach.

4

Terminated workflows still stay in the system for the retention period. Would you explain why keeping workflows open violates GDPR?

5

Hi, I’m a Fatjon’s collegue. The retention period of terminated workflows is a good point. Thank you.
To comply with GDPR regulations, in addition to having to delete data under certain conditions, we also need to be able to search for it for reporting purposes to final user. The idea is to save the data for short periods only and then delete it.
It’s not about breaches, but about avoiding loopholes or errors in GDPR data management.

We are evaluating to restore/fast-replay an equivalent workflow with outside data (not a replay from history) or a “goto step N”.

6

Hello Maxim,

Thanks for your insights. I’m still a bit uncertain about how keeping workflows open aligns with GDPR, particularly regarding personal data that might be part of the workflow’s state. My concern is about workflows potentially holding onto sensitive user information for longer than necessary, which could be seen as a GDPR issue.

Could you clarify how we can ensure that keeping a workflow open doesn’t inadvertently lead to GDPR compliance risks, especially if the workflow state includes personal data? Are there specific practices or configurations within Temporal that help manage these concerns effectively?

Appreciate your guidance on this!

7

Could you clarify how we can ensure that keeping a workflow open doesn’t inadvertently lead to GDPR compliance risks, especially if the workflow state includes personal data?

  1. You have to keep this state somewhere for the duration of the use case. I don’t understand why keeping it outside of a workflow is GDPR compliant and within the workflow is not.
  2. The workflow state should be encrypted and can use client-specific keys if needed. So, you can always delete the keys without actually deleting the state.
  3. Most security-conscious customers don’t send PII data through workflows, even if it is encrypted. They store it in special PII stores and pass IDs of that data through workflows.