When a custom form is updated on a request, make update on same custom form on the resolving Project | Community
Skip to main content
Tvasilovic
Level 3
August 16, 2023
Solved

When a custom form is updated on a request, make update on same custom form on the resolving Project

  • August 16, 2023
  • 2 replies
  • 2491 views

Hello!

I am attempting my first scenario and can't quite seem to get it working, so I am seeking input on how to go about this.

Here is the goal:

A User submits a request.

There is a custom form on the request that the user will make updates to as the Project progresses.

The custom form is also on the resolving Project.

The goal is to have the automation detect when updates are made on the Request custom form and make those updates on the Resolving Project's matching custom form so the Project Coordinator does not have to manually make the updates on these projects.

The scenario will need to monitor all the active requests in a specific request queue and move the updates from each request to the corresponding resolving project.

I had a very simple scenario built to start but it only works 1:1. one request to one project, once I began adding in other requests to the test queue thing went off the rails.

 

thank you for any pointers or examples or anything! 

 

****UPDATE****

I currently have two scenarios that I have created to do this, they are both working very similarly. The problem is this: they both appear to get triggered by an update activity, when an update happens the scenarios will map all the fields on the form from the issue to the resolving project, and do so for all issues in the request queue being watched. So all the fields are getting overwritten on all the resolving projects with each update. One problem that occurs with this is that I have set up an email notification to go out, so the Project Coordinator is aware new data has come in, and allows a sort of trail of changes. Unfortunately, with all projects getting "updated" (even if there was no actual update made to that issue/project) a notification email goes out for every project, which is not helpful.

 

 

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

If the requestor is always modifying the original request, then here is what I would do.

  1. setup a webhook to watch for issue modifications on issues from your request queue, and that have been converted to a project. This will let Fusion know that an update has occurred.
  2. Determine what changed. Because Workfront doesn't include what specifically changed, you'll have to determine that within your code. The easiest way I've found to do that is by generating a list of your keys from the "new" trigger, and iterate thru that list. Then, create two variables, one called "old value" and one called "new value". Next, place a text aggregator that will pull aggregate those two variables. In between the variable and the aggregator, place a filter that will only pass thru if old != new. Your text aggregator can be whatever you'd like, for example {key} changed from {old value} to {new value}. Some of the keys are system-generated values so won't ever change, which you can filter out immediately after the iterator to reduce your number of functions used.
  3. Place an update call to the project with all of the values that could change for simplicity. It won't update if the values are the same, but doing this you don't have to modify your call based on what changed, you can just make a single consistent update call.
  4. Create an update on your project, with the text 

    New Update on <Project Name>

    the following updates were made:

    {text from text aggregator}

2 replies

Tvasilovic
Level 3
August 16, 2023

Oh, and also it would be nice to send out a notice to the Coordinator about the updates. Ideally I wanted the notification to point out the updated fields, with field name and the updated data. Something like:

 

New Update on <Project Name>

the following updates were made:

<Retail Price> updated to <text>

<Tracking Number> updated to <text>

CrisDonaldson
Level 3
August 17, 2023

Hi,

 

If I am understanding correctly, I think I have an idea. Are you converting the Request to a Project? If not, can you convert the Request to a Project using the Misc Action module. Choose "Copy Custom Data" and add in "preserveIssue" under "Options". This will add in the Resolved By field and when an update is made to the Project, the Request will get auto-updated by Workfront.

 

Cristina

Tvasilovic
Level 3
August 17, 2023

Hi Cristina,

 

Thank you for the idea! Yes, we are converting the requests to projects. The custom form is updated by the Requesting user on the Issue and needs to get auto-updated on the resolving project. Which is the opposite direction from what you are describing. I'll keep this in mind, maybe that Misc Action module has some use in this scenario.

ChrisStephens
Community Advisor
ChrisStephensCommunity AdvisorAccepted solution
Community Advisor
August 23, 2023

If the requestor is always modifying the original request, then here is what I would do.

  1. setup a webhook to watch for issue modifications on issues from your request queue, and that have been converted to a project. This will let Fusion know that an update has occurred.
  2. Determine what changed. Because Workfront doesn't include what specifically changed, you'll have to determine that within your code. The easiest way I've found to do that is by generating a list of your keys from the "new" trigger, and iterate thru that list. Then, create two variables, one called "old value" and one called "new value". Next, place a text aggregator that will pull aggregate those two variables. In between the variable and the aggregator, place a filter that will only pass thru if old != new. Your text aggregator can be whatever you'd like, for example {key} changed from {old value} to {new value}. Some of the keys are system-generated values so won't ever change, which you can filter out immediately after the iterator to reduce your number of functions used.
  3. Place an update call to the project with all of the values that could change for simplicity. It won't update if the values are the same, but doing this you don't have to modify your call based on what changed, you can just make a single consistent update call.
  4. Create an update on your project, with the text 

    New Update on <Project Name>

    the following updates were made:

    {text from text aggregator}