We have various pipelines, for various sales cycles and sometimes various types of contacts or companies.

The Deal's information we need to access depend on the pipeline the deal is in. Since the "default deal properties" is made to display the "most important" information of a deal, we need this group of "most important" information to be pipeline specific.

Our suggestion:

To propose to create multiple "default deal properties", each one having a name. Then, admin should be able to decide to which pipeline to apply this "default deal properties". A "default deal properties" may be applied to one or more pipelines. It's ok to have a limit on the possible numbers of possible "default deal properties" if needed. 10 or 20 maximum would already be amazing.

Note: I've written the above with the understanding that "default deal properties" are controlling both the "about" section on the deal and the properties available when creating a new deal on the card that's opening on the right of the screen.

(Although we need this feature in "Tickets" as well, but the main idea remains the same).

It makes sense to have different properties for different pipelines in the process. We currently see Pipeline A as our daily business process for complaints, but pipeline B (that could be returns in our case) are completely different ticket properties.

You may want to ask in pipeline A why the ticket has been opened (product damaged/shipping in delay etc.), but you never would want to see these "default" properties in your pipeline B, since (in respect to returs) you may want to set properties like why the parcel has returned for example.

Therefore I really hope HS takes this request that has been opened for a long time now into action and tickets/deals will be available with different properties due to the choosen pipeline they are in.

Really all we really need in our company , is to define what properties we'd like to see when we create a deal in certain pipeline... there are some initial properties that do not apply to all pipelines... right now we have to add an option in each property that says "N/A" to show that that property in particular does not apply to that pipeline... sounds easy to do