Have you started using multi-object custom forms? Book a call with Product team to discuss your feedback.

[LilitM]

Hi, everyone,

With 2022.2 release last week, we enabled the ability to have multi-object custom forms. This means that now you can attach the same custom form on several object types instead of having to maintain copies of the same form for various objects.

Do you have any feedback you'd like to share or questions that I could answer? Also, please feel free to book a feedback call to discuss any further comments or questions directly with us.

Thanks!

Lilit

[skyehansen]

Feedback -- I thought it was interesting that the first two system admins in the Skills Exchange mentioned functionalities that seem to imply reasons NOT to use multi-object forms. One of them suggested reordering fields and sections between objects and the other mentioned calculated fields that are different from object to object. Does this affect your roadmap or the way you consider multi-object custom forms?

[LilitM]

Hi, Skye,

Great points. In general, we're going down the path of keeping multi-object forms generic, which means that at this point we will not support having different field orders/configuration for each object type. In such cases you'll still need to use separate custom forms for now.

As for the calculate fields, here again the fields referenced in the expression need to be compatible for all object types. However, we've introduced a new wildcard $$OBJCODE which you can use in expressions to differentiate the calculations per object type. For example, you can have a form for project and task object types, and you can create a calculated fields with this calculation: "IF($$)BJCODE="PROJ",Owner.Name,Assigned To.Name)". In this case the calculated field will show the project owner's name if attached on the project, and Assigned To user's name if attached on tasks.

If possible, I'd like to discuss any further feedback or questions over a feedback call.

Thanks!

Lilit

[skyehansen]

thanks for the heads up on the new wildcard! I'll take a look. We often add/subtract fields or reconfigure custom forms on different objects so I probably won't have any feedback on the rest :)

[skyehansen]

oh I do have one more question! Do you see a future where instead of data being transferred on conversion, it's simply the same data on both objects? So if I update something on the request it will also update the project?

[CalvinFold]

@Skye Hansen‚

• We have adds/subtracts between object types as well. One interesting solution might be if the new wildcard could somehow be used with the existing show/hide functionality. So if it is a certain object type at least some fields could be added or removed via hiding/revealing. I know this doesn't solve the re-order issue though. And because of this, yeah, a fair number of our forms can't used the multi-object functionalities. I also worry if we create a multi-object version and someone wants an object-specific tweak, then what? How do we make the change back to single-object versions and preserve data?
• I wouldn't want the data replicated between "per-object copies" to be the same on each object once the copy is made, so I want to (as always) make it clear if others think that if such a functionality is needed, it be optional behavior.

[LilitM]

Hi, @Skye Hansen‚ ,

That's an interesting idea. Currently that's not on the roadmap to be honest, but I'd like to see how much support it gains from other customers. Can you please submit that as an idea in Innovation Lab?

[LilitM]

Hi, @Kevin Quosig‚,

Currently we're trying not to add too much complexity in multi-object forms, at least in this phase, so we have no plans for displaying/hiding fields based on the object type. So for now the forms that require different fields or order for different object types still need to be kept separate.

[RandyRoberts]

We have only one form out of our 17 forms that gets used on two different objects; issue and project. Since there is precious little documentation on this subject, I haven't tried combining them.

There is another ongoing discussion about this HERE

[LilitM]

Randy, I hear you! I'll work with our Documentation team to add a help articles specifically outlining the implications of using a single-object vs multi-object forms. In a nutshell:

• If you remove an object type from a form, we treat it as deleting that form for the object type, thus all saved data will be removed from objects
• Section break security permissions must be the same for all form objects. We have updated the permission options to be the same for all object types. We have standardized the permission options for all objects to View, Limited Edit, Edit and Admin Only. Limited Edit is available for Projects, Tasks, Issues and Users. So if you create a project form with Limited Edit section permission, and then add a new object that doesn't have that permission option (ex. Portfolio), you will be prompted to use Edit permission for all object types instead.
• Fields references in calculated fields also need to be compatible with all object types. However, you can use $$OBJCODE wildcard to save different expressions based on the object types.
• Multi-object forms and data saved in them will be automatically transferred during object conversions (issue to project, issue to task, task to project), including when converting using templates. No need to manually add or adjust the forms during the conversion process.

Hope this helps. I'll be happy to discuss more details in a feedback call that you can book here.

Thanks!

Lilit

[michaelddemares]

Is there a way to have the project form copy over and sync with a document using the same form within the documents section of the project?