I’m assuming that you want each container to correspond with a specific document (and that is why you named it the ID of the document). If that is true, I would recommend designing your lucid collections to store the documentId alongside any other data (this would be done when defining your lucid collections). That way, when creating the hardrefresh/poll actions, you would be able to access the documentIds via the DataConnectorActionContext.documentCollections.
Are you setting up the containers in Azure from Lucid via an API call? If so, are you doing that within the editor extension, or have you set up some sort of patch action within the data connector? I would ensure that all communication to Azure is done through the data connector, as that will streamline both how you store and access the data on Lucid, as well as what is sent to Azure. When you initially create a container in Azure via Lucid, you would handle this in a patch action defined in your data connector. Since you would have defined the collections to hold the documentId, you could then communicate to Azure the documentId (as well as any other data you need to send) as well as communicate to Lucid to save these same collections, so that they are included within the actionContext of the hardrefresh/poll actions.
Let me know if I made any wrong assumptions here or can help explain anything further!