You develop a model-driven app to include a form containing several columns. Two groups of users. named Group1 and Group2 will access the form. A column contains sensitive data that should not be…

Question

Options

• ACreate a security role for users in Group1 to grant users access to the column.
• BCreate multiple forms. Assign a form containing the sensitive data to Group1. Assign a form that
• CUse JavaScript to set visibility of the column based on the group of the current user.
• DCreate a field-level security profile for Group1 users to grant the users access to the column.

• A
  6% (1)
• C
  11% (2)
• D
  83% (15)

Explanation

Field-level security profiles are the correct mechanism in model-driven apps because they enforce access restrictions at the column (field) level on the server side - meaning Group2 users literally cannot read the data regardless of how they try to access it (UI, API, or export). You create the profile, enable field-level security on the column, and grant read access only to Group1 users or their team.

Why the distractors fail:

• A (Security role): Security roles control access at the table level (create, read, write, delete on entire records), not at the individual column level - they cannot restrict a single field within a form.
• B (Multiple forms): Assigning a form without the sensitive column to Group2 only hides it in the UI; the data remains accessible via Advanced Find, the API, or other tools. Form assignment is presentation, not security.
• C (JavaScript visibility): Client-side JavaScript can be bypassed by disabling scripts or using the API directly - it is a UX mechanism, not a security control.

Memory tip: Match the granularity of the tool to the granularity of the requirement. Securing a whole table → security role. Securing a specific column → field-level security profile. If the question says "sensitive column," think field-level security profile every time.

No community discussion yet for this question.