You shouldn’t “revive” a terminated BPT instance; you should start a new one.

In OutSystems BPT, once a process instance reaches an End or Terminate node, that instance’s lifecycle is logically finished. The engine and monitoring features (Service Center, BAM, logs) all assume that:

• The instance will never execute more activities.
• Its current activity is stable and will not change anymore.

Trying to force it back into Active and fire a Conditional Start for the same instance will break those assumptions and can lead to subtle and hard‑to‑debug issues.

Main risks and drawbacks

1. Engine state vs. database state mismatch
   BPT execution state is managed by the platform, not just by your business tables. Manually changing status/records at the DB level bypasses engine logic:

   • The engine might not reschedule timers/activities for an instance it considers completed.
   • Internal state (current activity, tokens, transitions) may no longer be coherent after the end node.
     This can cause processes to get stuck, execute in unexpected order, or throw runtime errors.

2. Broken semantics of “End” / “Terminate”
   In process design, End/Terminate means “this instance is done”:

   • Conditional Starts are designed to start new instances or subprocesses when conditions are met, not resurrect old ones. Introduction to Business Process Technology
   • Using Conditional Start on an already‑terminated instance breaks the mental model for anyone reading or maintaining the process.

3. Monitoring and reporting issues (Service Center / BAM)
   Monitoring tools assume a monotonic lifecycle (Running → Suspended/Error → Finished):

   • Counts of Active / Suspended / Finished instances may become inconsistent. Understanding BPT Process Limits
   • Dashboards, KPIs, SLAs, and BAM reports can show misleading numbers because an instance that was “finished” reappears as “active”.
   • Historical analysis becomes unreliable (e.g., average duration, throughput), since one logical business case will be stretched and reused as if it were multiple runs.

4. Change impact and versioning problems
   Processes are versioned artifacts. Suspended/active instances can be impacted when you publish changes (activities removed, paths changed):

   • The platform has defined behaviors for Active/Suspended instances when a new version is published. Understanding BPT Process Limits
   • Manually toggling a finished instance to Active may put it in a state not covered by those rules, leading to unexpected suspensions, errors, or orphaned activities.

5. Concurrency / resource utilization
   The platform controls concurrent execution slots per front end and schedules work accordingly. Understanding BPT Process Limits

   • “Zombie” instances reactivated outside normal flows may occupy slots unpredictably.
   • This can affect fairness and throughput for other, correctly started instances.

6. Integrity of business logic
   From a business perspective, a terminated process usually means: final decisions taken, side‑effects executed, external systems updated.

   • Reusing the same instance for a “second run” can accidentally skip or double‑execute effects (notifications, integrations, DB changes).
   • Auditing becomes harder: one instance ID now represents multiple business episodes.

Recommended approach

Instead of reviving a terminated instance:

1. Model “re‑run/reopen” explicitly in the process flow

   • If you might need to reopen a case, add a branch or loop in the process that leads back to the appropriate activity while the process is still logically alive.
   • Use Conditional Starts or events to trigger subprocesses or new instances that are designed for the “reopen” scenario. Introduction to Business Process Technology

2. Start a new process instance and link it to the same business entity

   • Keep the original instance as historical record (finished).
   • The new instance references the same business record (e.g., CandidateId, RequestId) and handles the new cycle.
   • Monitoring, logs, and KPIs remain consistent: each run is a separate instance.

3. Use business logic to decide which path to follow

   • The new instance can check current “Record State” and decide whether it’s a fresh process or a “reopen” scenario.
   • That gives you full control while respecting platform semantics.

Summary

From a platform/runtime perspective, “reactivating” a terminated BPT instance by manually flipping its status and triggering Conditional Start is unsafe and not supported by the BPT model. It risks process integrity, monitoring correctness, and future maintainability. Starting a new instance (possibly through a dedicated “reopen” flow or subprocess) is the robust and recommended way to handle reactivation scenarios.