How would you create a cross-project predecessor relationship between tasks using Fusion 2.0?

[Rick_MacDuffie]

Afternoon folks,

I'm investigating a business scenario which is meant to keep a Pair of projects' schedule in sync (so to speak). Essentially, Project A starts first and at a certain point the business branches off and starts Project B. Project B cannot complete until a particular task approval from Project A is completed.

Manually adding the predecessor works just fine, but we're hoping to trigger Project B automatically based on that Project A task being set to Complete : Pending Approval AND setting the appropriate cross-project predecessor up at the time of creating Project B (without a PM getting involved).

I was imagining I'd need to use a Custom API Call module to add a PRED object, but I immediately bump into the following error:

[422] PRED is not a top level object and can't be requested directly in internal.

Not finding an alternative to use Update Record module, or Misc Action, module, etc. Read Related Record will get me the predecessors. It seems like I need an Update Related Record module or something similar.

Anyone done this?

[darin_patterson · Accepted solution]

Hi Rick,

If I understand the task at hand properly, the goal is to use Fusion to create a predecessor relationship on a task. If that's correct, here's how that can be achieved.

Your instinct about using the Custom API Call module was correct. The only difference is that, instead of creating the predecessor directly, you'll actually update an existing task (or create a new one) with the predecessor(s) as part of the collection of related predecessors.

To update an existing task with a predecessor, your Custom API module should be a "PUT" to

TASK/{{TASK THAT HAS A PREDECESSOR}}

with the following body

{

"predecessors": [

{

"objCode": "PRED",

"isCP": true,

"isEnforced": false,

"lagDays": 0.0,

"lagType": "d",

"predecessorID": "{{PRED TASK ID}}",

"predecessorType": "fs",

"successorID": "{{TASK THAT HAS A PREDECESSOR}}"

}

]

}

note: "isCP" is set to true based upon the assumption that it is a "cross project predecessor".

If you have to do updates later, you'll want to make sure you to do a GET so you can pull the full list of predecessors and update all of them. Doing a "GET" to TASK/{{Task ID}} with fields=predecessors:* may be good to do anyways to see how it is structured on an existing task with predecessors.

I hope that helps.

[Rick_MacDuffie]

Thanks Darin! I think that is exactly what I needed. I just started to head down the path of trying to update the collection of predecessors on the TASK object using the Custom API Call module. I ought to be able to construct a good request from your sample above.

Thanks for the help!

[Rick_MacDuffie]

Confirming. This was definitely the route needed.

1) Custom API Call to grab any existing predecessors on the task you want to add a predecessor to (seems to be a more direct route than Read Related Records).

2) Use the Transform to JSON module on the returned predecessors array.

3) Compose a string, using the transformed JSON string and the blob Darin provided with the appropriate details.

4) Custom API Call against the task object, using the task ID and putting that composed string in the body of the request.

Works like a charm! Thanks again @Darin Patterson - inactive‚ !

[DanielCo]

Darin,

‚

Is this usage of the message body documented? I feel like the documentation I have seen says to use the query parameters to supply field inputs for a put.

‚

Thanks

Daniel‚

@Darin Patterson - inactive‚

[darin_patterson]

Hi Daniel,

Thanks for that note. We are working on some significant updates to our API documentation (you can access a beta version here). I really don't know why the older documentation uses query parameters for PUTs.. It technically works, but that is very "non-standard".

I'd even suggest that it is a best practice to use standard JSON body for POST and PUTs. (there may be some exceptions when the PUT is an action that does not require a body).

[DanielCo]

Thanks, Darrin. That documentaion is looking great excisted to see it when it's ready to go. I would also add that it would help if there was a section that gave general instruction regarding the way GET, POST, PUT and DELETE calls should be structured independent of a specific object. dc