Odd happening with Document IDs going missing between trigger and read modules! | Community
Skip to main content
S
stuartcairns
Level 4
June 24, 2021
Question

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

  • June 24, 2021
  • 3 replies
  • 1604 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

3 replies

C
CiaranCa
Level 4
June 24, 2021

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?

S
stuartcairnsAuthor
Level 4
June 24, 2021

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.

D
darin_patterson
Level 4
June 24, 2021

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.

Doug_Den_Hoed__AtAppStore
Community Advisor
Doug_Den_Hoed__AtAppStoreCommunity Advisor
Community Advisor
June 24, 2021

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

S
stuartcairnsAuthor
Level 4
June 28, 2021

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
Community Advisor
Doug_Den_Hoed__AtAppStoreCommunity Advisor
Community Advisor
June 28, 2021

Huh: interesting one, Stuart.

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

Regards,

Doug

Terms & ConditionsAccessibility statement

Loading footer...