At the moment, all custom fields in a department's ticket layout must be populated correctly before a ticket can be created or modified. This has some benefits, but a number of setbacks. We will need to discuss if the current way these fields are handled is correct. Different rules could be decided for PUT vs POST commands.


Hidden conditional fields - A layout may have hundreds of potentials fields hidden, which display only when they match other criteria. This is going to problematic, as you have to then start filling the fields with fixture data to get the API call through, which goes against the logical worklow of tickets, incorrect data is stored, and it corrupts reporting (total tickets created with field X, populated with selection Y) - and has many other side effects

Mobile App behaviour - This is an open report for the mobile section to make this clear - if a ticket has required fields (shown or hidden) and these are not filled, it will result in an API error. 

API V1 - The legacy API allows you to populate fields regardless of whether they are mandatory or not. Customers are opting to use parts of this API for that reason.

Mandatory fields are just for the GUI - When a user emails in, the email is not rejected as it has insufficient custom fields defined. Similarly, triggers/escalations and other parts of the system allow you to bypass the requirements for functionality sake. An API call arguably should behave the same as an email here.