I understand that if I set it as attribute level is supersedes the field level, but in which scenario does it make sense to have different at Field level? For subpages with different rights to some folks and make them populate it?
If you are not using partitions, there’s no difference, except that you can see at the attribute level that the field is required, without having to drill into views/field properties to see this.
If using partitions, you can make the field required on one partition, while leaving it optional, or even not visible, on another partition.
For instance, one might setup partitions based on project business processes, say Development vs. Application (in our industry, this is equivalent to Product Launch) – for Application projects, we have customers and want to make the Customer field required. For Development projects, we may or may not have a customer – so here, we’d want the Customer field to be optional.
Of course, adding partitions can make things more complicated than they need to be. In the above scenario, one might elect to forget partitions, make Customer field required on all projects and supply a look value such as “Internal” or “[Your company name here]” for those Development projects which don’t have an external customer.
I recommend avoiding partitions unless there is some real value add for using them. Once partitions are used, people want to do more things differently and these things are not always value added – may be valuable to the resource requesting the difference, but not to one’s company.
Here is one another difference.
When fields set as mandatory at the attribute level, Clarity would expect us to pass values to such fields even while xogging a Project as well.
While set only at the field level, it will not expect it while xogging.
Retrieving data ...