Odd happening with Document IDs going missing between trigger and read modules!

[stuartcairns]

Hello all

I have a scenario that starts with an instant watch for new document versions being created. It gathers Version ID, Document ID, name etc. The next module gathers document-level data. The trigger runs ok and the version and document IDs are shown in the execution inspector but the second module fails saying the document ID doesn't exist. Also, when I use the document id shown in the execution inspector and search for that in Workfront, it's not found but when I use the document name from the trigger module, it is found, but it has a different document id to that shown in the execution inspector of the trigger module. My mapping of the document id from the trigger module to the read module is correct so I'm a bit stumped. Does Workfront do something odd with document ids in the background?

Thanks v much

Stuart Cairns

[CiaranCa]

A couple of screenshots would be helpful, but if the documentID in the webhook doesn't actually exist when searched for, i'd double check the connections being used by each module, do you have multiple sandboxes/regions?

[stuartcairns]

Hi Ciaran. I've loaded some pictures, sanitised a little. I think it shows a clear story. I've put the screenshots in a word doc because I can load only a single doc into the record here.

[darin_patterson]

Hi Stuart, thanks for those detailed screenshots. I apologize for the basic nature of this point, but are you positive that the first module is receiving events from the same instance that the 2nd module is interacting with?

I only ask because it's the only thing I can think of and I have been stumped by this myself once.

[stuartcairns]

Hi Darin

Thanks for that and no need to apologise. Check the simple stuff first is always best. I'm very sure I've not got environments mixed up. My read module is definitely pointing at production. My trigger is also because it works the vast majority of the time and all the docs are in production. Actually, we don't have proofing in our DEV instance anyway so I couldn't get that wrong. Incidentally, I'm assuming there is no way to check the config of a webhook once it's been created but please let me know if there is a way I'm missing. I see Doug has posted a suggestion too with a testable theory so I'll try that and see how we get on. I'm really going to stuggle today for the time so the next post ay not be until Monday.

Thanks again.

Stuart

[Doug_Den_Hoed__AtAppStore]

Hi Stuart,

Following, interested, and as is Darin, puzzled. But I have another theory.

Where I would expect a drag-and-drop-new-version to keep the same Document ID before and after, what you're seeing behaves the way a delete-original-upload-new version...which would also then match the "version: 1" shown in your screenshot. If the intention of your scenario is to only capture new versions of existing files (i.e. the former), if you added additional criteria to exclude "version: 1" events of brand new documents automatically creating their corresponding initial version (i.e. the latter), I expect you would then remove the "noise" that we're observing.

If I'm following correctly that it is indeed the former you are after, would it then be possible to repeat your test, but include screenshots confirming the Document ID in production before (and after) initiating the intentional (e.g. "version: 2") drag-and-drop-new-version behavior...which I then expect will have the stable Document ID we all expect?

Regards,

Doug

[stuartcairns]

Hi Doug

Thanks v much for this. So you're theory is that the user is loading a document, thus creating V1 and then instead of adding a V2 they are deleting the V1 and then adding another version thus creating a new V1? Would that result in the original document id (as opposed to the version id) being deleted? V interesting theory. I'll definitely test that and post the results. I'm supposed to be not working today but I'm very curious so I'll see what I can do but it may be Monday before I post the results.

Thanks again

Stuart

[Doug_Den_Hoed__AtAppStore]

You bet Stuart,

Whether a user’s first deleting an existing file (to replace it), or simply uploading a new file, since Workfront will automatically generate a “version: 1” current version at that instant, with (yes) a brand new Document ID, theory such events are causing “noise” for your scenario (being focused on only “version: 2” or better, so my suggestion, if so, is that you skip such “version: 1” noise.

Regards,

Doug

[stuartcairns]

Hi Doug

Thanks again. I've done some tests and my results are below for interest. For context, what I'm trying to do (& it's working perfectly for the vast majority of cases/bundles) is that I need to send an email to task assignees when the Primary Decision Maker of a proof generated from a version registers a decision of 'Changes Required'. If anyone else registers a decision then no email is to be sent. Also, once the email has been sent, no further emails are to be sent for that version. The proof HQ connector detects a decision being made but not who made it and not when they made it (in the trigger output) so all you can do is fire the scenario that reads the proof details and reviewer details (two modules). So to enable this use case I have a custom form with a custom field that is used to show whether the email has been sent or not. Because I can send only one email per version (when the PDM registers 'Changes Required') and because you cannot have custom forms / fields at the version level I have to have the custom field at the document level and then reset the field when a new version is created. So I do need to set the field when the V1 is created and all versions thereafter.

Results: Deleting V1 when there are no other versions deletes the entire document. Deleting V1 after V2 has been created doesn't re-create the error. I've also looked at the original occurrence and there is only a V1 and no system updates suggesting any were deleted. I've raised a ticket and a support engineer is going to take a look. All the best, Stuart. I'll advise here when we get it sorted.

[Doug_Den_Hoed__AtAppStore]

Huh: interesting one, Stuart.

Good luck with it, and I look forward to hearing how it turns out.

Regards,

Doug