LEARN. PRACTICE. GROW.Concept and mechanism
Personalizing a Core UI form changes the current user’s experience. Configuring the form changes the shared design intended for users. Personally hiding a field neither deletes it from the table nor changes authorization to read its value. A configuration change should identify the affected view and interface because a workspace can have its own components. Groups support administering responsibilities and associating roles; inheritance of a group role depends on the association and its Inherits option. Assignment-group membership and access authorization are related concepts, but they should not be treated as equivalent without checking the applicable rules.
Guided application
Consider a team needing functionality supplied by a plugin. Check availability, dependencies, subscription, and activation method before planning the change. Documentation describes plugins enabled by default, customer-activated plugins, and others requiring provider action. Do not promise that every activation can be undone with a button: limitations and specific rollback cases apply. Prepare a nonproduction instance and acceptance criteria first. If only one analyst cannot see an already configured field, inspect personalization before changing the view for the whole team. The solution should match the problem’s scope and make clear who receives the change.
Field hidden by one person: check preferences and view before redesigning.
Common pitfalls
Broad role used to fix visibility; plugin treated as a reversible preference.
Related topics: Instance, navigation, and context · Records, collaboration, and analytics · Knowledge and catalog
Connect configuration, affected audience, and validation method.
Reference: Personalize a form · CSA blueprint January 2026