Similar to dependent picklist is there a way to create a dependent 'section' of fields on a record. For example: make a "partner section" on the account view only viewable / editable if account type is set to "partner".

It would be REALLY, REALLY great if we could have fields CONDITIONALLY appear on an edit page based on the values entered in other fields.

i.e. - If a person chose a certain value in a picklist, a text field would appear somewhere else on the page.
(or maybe it would change from Read-Only to editable)

or - If a person entered a value in one text field, another field would appear or become editable.

or - if a person selected a checkbox, a certain value would automatically get selected or entered in another field (a picklist or multi-select picklist perhaps) (I know you can do this with Workflow field updates, but that can be kind of clunky or just not feasible in certain circumstances)

Any other suggestions for possible edit page interactions?

It would be immensely useful if it was possible to apply conditional formatting to fields, using formulas. The image is an example of this type of functionality, from Microsoft Excel. So for example we can show a field in a specific colour if it exceeds upper or lower thresholds (like the dashboard speedometer). We can highlight a match between a field and another related field, to highlight duplication, or a positive match. Salesforce has a fantastic visual appeal to it that makes it easy to use, and conditional formatting will take it to the next level of development as it means all users can much more easily interpret the information presented - something that for complex objects with many fields is absolutely essential. Also, we must recognise that for some fields we can't mandate validation, but in reality we really want content in them - it's a grey area. Currently with these situations we have to have validation, or not have validation. But by using colours, we can highlight fields based on value - so for example all staff know that RED fields need attention, and so do ORANGE fields, but to a lesser degree. Whatever our business processes are, we can very effectively all use colour to highlight potential issues and help our users understand the information they're looking at, whilst improving data quality by grading fields based on their content and relationship with other fields.

"This is really important - we need to create workflows that make a field appear after a certain value has been clicked in another field
Object(s) affected - All
Business Benefit - Data accuracy
Group(s) Affected - Administrators"

Dynamic page layouts -- the ability to conditionally change the display attributes of fields & sections on a page layout, based on data conditions. Hide / show / make disabled / make required / etc.
This would clean up a lot of our layouts. The user would see only the info they need based on certain conditions. This also voids having to use a ton of validations rules on one layout.

When will we have Dynamic page layouts? by this I mean that instead of fields with dependancies being greyed out until triggered, why see them at all? Why can't the page load fields once they are required?

I'd like the ability to have field dependency work with other fields that are not picklist values AND have a required field serve as a trigger off of that dependency field. For example, I'd like to create an Opportunity field dependency on field Stage with a currency custom field. Projected Annual Revenue (a custom opportunity field) should be dependent on Stage. Projected Annual Revenue should be required.

It would be great if upon selection of a particular value in a controlling field, selection of a value in the dependent field would become REQUIRED.

As it stands now, a user has the option of leaving the default (-None-) value in the dependent field or not selecting anything at all...

We would love to see dependant field and not just pick list for example our case reason could be "Loan Discharge" then if this is the reason a field could appear with the date required for the loan discharge, but hide the field until that case reason is chosen.

Field dependencies should allow making a field required (including text fields, not just picklists and checkboxes) dependent on the selection in a controlling field. Currently, required fields can only be set to be universally required.

Currently this is done via validation rules, but that is bulky and forces the user to click 'save' before realizing their mistake/omission.

Allow user to create a custom text field to be dependent to the values of a custom pick-list field.

Example:
- Custom text field: Field Label
- Custom pick-list field: Request Type with pick-list values of: Add New Field, Revise Field, etc.
- Scenario:
If user selects the "Add New Field" value in "Request Type" field, then make the "Field Label" field be a required field.

It would be very helpful if one could set field dependencies on a non-picklist field. This would help organizations in further refining workflow.

When one field is updated to a certain drop down item, render the mandatory fields not mandatory. For example, if a lead is unqualified, there should not be a requirement for an Industry and Category (but these are mandatory fields for all other Lead Statuses)

Don't think there's much more I need to enter on this, we simply need to have the ability to make text fields dependant and required upon other fields being checked or from a pick list value.

Or just allow picklists to activate/deactivate text fields.

I would to configure a field to be displayed/not displayed based upon a dependency rule.
It can make the UI much more friendly.

When doing approvals in Salesforce, I want to put in an automatic date when the Approver changes the status to Approved. At the moment dependant fields have to be picklists - can you look at this?

Would love to have the ability to hide/display case fields based on field dependencies. Currently, a field may be 'grayed' out but still displays on the page. Would like it if field could be hidden unless certain criteria was selected.