Level 2

Solved

Looking for a way to take one intake request with multiple actions to split them into multiple projects.

Forum|Forum|2 years ago
April 25, 2023
6 replies
2294 views

Many of our marketing teams have a single intake form where intent requestors can ask for multiple actions and channels. However, the work associated with the different asks and/or channels requires different teams and/or different levels of effort (and often a different template). My understanding is that an Issue can only be associated with one project. How are folks in the community managing this? Thanks!

Workfront

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

I have built a very similar use case to this with Fusion. In the one that I think works the best, we configured it like this.

1. In the request form, there were several text fields. Each text field represented the type of deliverable they wanted, and then if they wanted multiple of the same deliverable they could add it in on a new line in the text field.

2. In Fusion, we then iterated thru each of the text fields, and in the text fields converted them to an array based on each line being an entry in an array

3. Then for all of those, a new project was created for each deliverable. Templates were based on which deliverable type the project was for, as well as some other criteria within the request form.

4. On each project, we copied down the original request metadata, as well as recording which request was the original request. Final project location was also based on information provided in the request form.

The end result was multiple projects, based on multiple and/or various templates, in different locations, based on a single request. Note that we preserved the originating issue with the project on a custom field, not on the default resolving object field, as that requires a 1:1 relationship.

Jason_JB

Level 5

Hello - is Fusion an option in your instance?

We leverage fusion to take an inbound request and then create the needed project and pull in a number of related attributes. Based on your description, I'm picturing something similar that could create the multiple items and replicate requests, if needed.

RandyRoberts

Community Advisor

That sounds pretty interesting, Jason. I've not toyed with that but I can see it being useful for split projects with multiple deliverables all related to a main project.

KellieGardner

Community Advisor

Correct, that it's a 1:1 relationship.

In a past life, we would convert to a single project with parent tasks as the individual pieces of the project and then the sub tasks for those tasks to complete but we only had 1 project manager that managed them all. If you are going to have multiple PMs managing the different deliverables, you might have to play around with some access permissions to give everyone proper manage access.

Project Name

Parent Task: Deliverable 1
- Task 1
- Task 2
- Task 3
Parent Task: Deliverable 2
- Task 1
- Task 2
- Task 3
Parent Task: Deliverable 3
- Task 1
- Task 2
- Task 3

ChrisStephens

Accepted solution

Community Advisor

I have built a very similar use case to this with Fusion. In the one that I think works the best, we configured it like this.

1. In the request form, there were several text fields. Each text field represented the type of deliverable they wanted, and then if they wanted multiple of the same deliverable they could add it in on a new line in the text field.

2. In Fusion, we then iterated thru each of the text fields, and in the text fields converted them to an array based on each line being an entry in an array

3. Then for all of those, a new project was created for each deliverable. Templates were based on which deliverable type the project was for, as well as some other criteria within the request form.

4. On each project, we copied down the original request metadata, as well as recording which request was the original request. Final project location was also based on information provided in the request form.

The end result was multiple projects, based on multiple and/or various templates, in different locations, based on a single request. Note that we preserved the originating issue with the project on a custom field, not on the default resolving object field, as that requires a 1:1 relationship.

ChrisStephens

Community Advisor

A thought I just had on this, you could possible create a top-level project that resolves the originating issue, then in that project create issues for each deliverable, and make resolving projects for each of those. This way you could preserve using the built-in resolving object functionality, and would allow the permissions/governance granularity you would be looking for, but with the cost of having the overseer project someone would have to manage.

RandyRoberts

Community Advisor

I like it! It would be worth testing it and then writing a procedure or cheatsheet.

B

BrendaCh

Level 2

We are exploring a pilot (without Fusion) to use one request issue for multiple resolving projects. The idea is for the Stakeholder to submit a full campaign brief that multiple project managers will leverage for their specialized projects. Ideally we want to keep the one issue, but convert to project as many times as needed, and show all of those resolving projects in the original issue (breaking the 1:1 relationship).

djmitchellAuthor

Level 2

Thank you everyone! We are going to give this a try with Fusion

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded