Ideally any Data Page - asynchronous or not - would not be making any assumptions about the data that is on the clipboard when it runs. Consider them stateless and having to take responsibility of sourcing all the data they need to complete.

If it is Operator ID information you need specifically, you could have your Data Page take an "OperatorIdentifier" parameter - to which your calling thread maps OperatorID.pyUserIdentifier when the Data Page is invoked. Then the Data Page would need to orchestrate its own lookup of the OperatorID instance from the database.

The same approach applies for anything dependent data persisted in the database - pass the key to the instance your Data Page needs as a parameter.

If it is specifically the pxRequestor clipboard page you need, this isn't persisted in the database so you would need to do some more engineering around that. Hopefully you only need some pxRequestor information that could be passed as scalar parameters to the Data Page. Alternatively, Data Transform pxRequestor into an instance of a custom concrete class that you persist and follow the above advice about passing keys as parameters. In its simplest (but heaviest) form, you have a custom concrete class with one Single Page property of type Code-Pega-Requestor, which you copy the whole pxRequestor page to before saving the instance.

If you wind up with this, ensure you have something that cleans up these custom class instances - they will be redundant after an hour so an hourly Job Scheduler would do.