Customize OOTB form at SPM or create a new form from scratch

[MatthildiP]

Dear all,

I have a dilemma. A client's business requires managing information and the lifecycle of some entity that resembles a project, but isn't exactly a project.
What's better? To add 200 new custom fields with embedded workflow to an OOTB form or to create a custom form?

Thank you

Kind Regards

[phil_bool_unifi]

200 fields isn't a project, it's a data dump.  Look again at those requirements.  The purpose of the project is to coordinate activities to make sure a shared objective gets met.

It sounds like that data is actually accompanying information, that may just be better attached as spreadsheets in associated documents.  You could look at document templates, or providing a URL out to an associated sharepoint, then using the Project to track the lifecycle. 

If some of this is a bespoke lifecycle, look at putting the steps into a Playbook, and running that on the OOB project record from the Project Workspace.

[MatthildiP]

Thank you for you time and your answer! 

You are right. 200 fields are too many! But the customer wants to filter records on those field, so unfortunately, they have to be custom fields on the form. So what is the best option? Add all these fields at OOTB form or customizing the existing one? 
Can you please help me with documentation for putting the steps into a Playbook, and running that on the OOB project record from the Project Workspace? This is a good idea.

Thank you again!

[MatthildiP]

Thank you for you time and your answer! 

You are right. 200 fields are too many! But the want to filter records on those field, so unfortunately, they have to be custom fields on the form. So what is the best option? Add all these fields at OOTB form or customizing the existing one? 
Can you please help me with documentation for putting the steps into a Playbook, and running that on the OOB project record from the Project Workspace? This is a good idea.

Thank you again!

[phil_bool_unifi]

When you say they need to filter on those records, is that because they need to report on them?  If so, that doesn't necessarily require they be part of the Project record itself.  It may be sensible to have one or more related record that captures the data, then when building the Platform Analytics Dashboards to show the output, you can use Related List conditions to filter data by those records.  

Try not to lose sight of the core functionality of the Project record:  It's about dates and times, managing costs, and making sure nothing gets missed.  
In terms of your fulfilment process, Playbooks are very intuitive.  Head over to the Playbook Designer and look at the default Playbook for Projects (or Demands if you're on an up-to-date version).  The majority of steps are just instructions to the Project manager, and you can add questionnaires to the Playbook to capture data points that only influence what task needs to be done next, and doesn't need to be reported on.  Once that's done, set the playbook's trigger to run on creation of the type of project you're working on, and you'll see it in  the Project Workspace.