The Use Case:
I have set up an offboarding journey for users leaving our company. This journey includes tasks that need to be completed before the user leaves, as well as tasks that must be executed after their departure date. By default, it makes the most sense to use the native "Requested For" field to identify the user who is leaving.
The Problem:
Currently, using the "Requested For" field makes post-departure tasks impossible to complete.
Imagine John leaves the company on April 30th. His AD account is automatically disabled on May 1st at 00:00. This status syncs to Freshservice, resulting in John’s Freshservice requester profile being deactivated. Because of this deactivation, the system automatically closes his offboarding journey and abruptly cancels all outstanding post-departure tasks.
The Workaround:
As a workaround, I am currently using a custom text box to capture the leaver's information instead of using the native "Requested For" field. However, this comes with significant disadvantages: it limits native automation capabilities, impacts reporting, and opens the door for manual entry mistakes and confusion among agents.
The Ask:
It would be highly beneficial to adjust the system logic so that offboarding requests (or tickets tied to the offboarding module) are exempt from auto-closure when the affected user gets deactivated. The journey should remain open until all dependent child tasks are completed.
