Hi ​@quodsimDan , thank you for your question. Someone from our team will reach out shortly help.

Hello Dan!

As of right now, it is not possible to get the documentId within a data action. Can I ask why you want the documentId in these instances?

Thanks for your response.  Here is what I am attempting to do.

An action is taken in LucidChart which triggers a web api call which results in files being created in azure blob storage container async.  In my current design, I passed the documentId to that action and the documentid is used as the blob storage container name.

I then wanted to create Poll and DataRefresh actions that check for the existance and contents of files in that blob storage container name.

My question was triggered when I was writing the Poll and DataRefresh method.  Both of those actions are automatic and such, do not take any parameters.  I was hoping I can fetch the documentId so that I could fetch the azure blob container associated with the document.

Based upon your response, I believe I need to alter my design.  The key to the design is to make sure Poll and HardRefresh and able to know what  blob storage container name is. 

Poll and HardRefresh do have access to Collection primary keys.  I could create an DataItem in a Collection where the Primary key is the Container.

What do you recommend?

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!