Object Manager and Lightning App Builder practice questions

Set the field visibility to hidden in the Lightning Record Page component visibility settings.

Why it fails: Component visibility in Lightning App Builder only hides the field on the page layout; it does not prevent users from accessing the data via reports, list views, or the API. Field-level security must be used to enforce actual data access restrictions at the user profile level.

Create a validation rule that restricts viewing based on the user's profile ID.

Why it fails: Validation rules are designed to prevent record saves when criteria are not met; they cannot hide fields from the user interface. Using validation rules for security purposes is an incorrect pattern because it does not restrict read access or data exposure through other platform features.

Change the page layout assignment for the Sales Manager profile to a restricted layout.

Why it fails: Page layouts determine which fields are displayed on the record detail page but do not secure the data itself. A user could still see the field in reports or list views if they have the proper object-level permissions, making page layouts insufficient for security.

Assign a custom permission set to the object.

Why it fails: Assigning a permission set is an optional post-creation task for access control. It is not part of the mandatory object creation wizard steps. While important for security, it does not prevent the object from being saved if skipped during the initial definition of the object.

Configure the lookup filter for the primary relationship.

Why it fails: Lookup filters are configured after the object is created and the relationship fields are established. They are not part of the initial object definition wizard. Attempting to configure them during the creation wizard is impossible because the relationship fields do not yet exist.

Deploy a custom Lightning component to the record page.

Why it fails: Lightning components are deployed via the Lightning App Builder after the object is created. They are not part of the object definition process. Requiring them during creation would be an incorrect workflow as the object must exist before the page layout or lightning page exists.

The lookup field must be created as a custom field on the parent object.

Why it fails: Relationships are defined on the child object, pointing to the parent. Creating the field on the parent would create a child-to-parent relationship from the wrong perspective. This is a fundamental concept in Salesforce schema design that prevents the correct establishment of the master-detail link.

The user must have the 'View All Data' permission enabled.

Why it fails: While 'View All Data' is necessary for certain administrative tasks, it is not a requirement for converting relationship types. The conversion is a metadata-driven operation that relies on record integrity within the schema rather than the permissions of the individual administrator performing the change.

Lightning App Builder

Why it fails: Lightning App Builder is used to arrange components on a page, not to define the internal structure of field sections within a record detail component. While it hosts the Record Detail component, the actual content and grouping of that component are driven by the assigned page layout.

Record Type

Why it fails: Record types allow you to offer different processes and picklist values to different users, but they rely on page layouts to actually define the field placement. A record type acts as a container for page layouts but does not contain the layout logic itself.

Compact Layout

Why it fails: Compact layouts are used to display key fields in the highlight panel at the top of a record page. They are not used for the main body of the record detail view, which is controlled by the page layout. They serve a different UI purpose.

Dynamic Forms require a record type to be defined.

Why it fails: Dynamic Forms can be used on objects without record types. While record types can be used in conjunction with them, they are not a prerequisite. This is a common misconception that confuses legacy page layout requirements with the modern functionality of the Lightning App Builder.

Dynamic Forms work on all standard and custom objects.

Why it fails: Dynamic Forms are currently supported on most custom objects and many major standard objects, but not every single standard object in the system. Administrators must verify support for the specific object before attempting to migrate existing page layouts to the new Dynamic Forms framework.

Page layouts are still required to control the 'New' record button.

Why it fails: While page layouts have historically controlled the 'New' record dialog, this function is being gradually transitioned. However, the statement implies that page layouts are still required for this specific task as a limitation of Dynamic Forms, which is an inaccurate characterization of the platform's current evolution.

In the Translation Workbench.

Why it fails: The Translation Workbench is used for multi-language support. While you can change labels there for specific languages, it is not the primary place to define the core object label. Using the Object Manager ensures that the primary label for the application is updated correctly.

In the Lightning App Builder.

Why it fails: Lightning App Builder is used to arrange components on a page. It does not contain the settings for modifying the object's schema or its metadata properties, such as labels or API names. Attempting to change an object label here is not possible.

In the Custom Metadata Types menu.

Why it fails: Custom Metadata Types are a specific feature for creating configurable application settings. They are not where standard or custom object metadata is managed. Changing an object's label here is impossible, as these are entirely different architectural components within the Salesforce platform.

Define Field-Level Security for profiles.

Why it fails: Field-Level Security is managed within the Object Manager, specifically under the Field and Relationships section for each object. The App Builder is focused on the presentation layer, not the security or access control layer, which is handled at the profile or permission set levels for the entire organization.

Create new custom objects.

Why it fails: Custom objects must be created in the Object Manager. The Lightning App Builder is strictly for designing the UI layout of pages. It does not provide the ability to define the underlying data structure, schema, or object relationships that are required to store information within the Salesforce database environment.

Text field.

Why it fails: Text fields allow users to enter arbitrary string data, which makes it impossible to enforce a predefined list of values. This leads to inconsistent data entries that are difficult to filter or report on, making it a poor choice when you need to enforce structured, controlled input.

Multi-Select Picklist.

Why it fails: Multi-Select Picklists allow users to choose more than one value from the provided list. Since the business requirement is to restrict the user to exactly one selection, a standard Picklist must be used instead of a Multi-Select Picklist, which would allow for invalid multiple-value data entries.

Number field.

Why it fails: Number fields only accept numeric values and do not provide a selection list. They are used for quantitative data, not for categorical or status-based selections where a user needs to pick from a specific list of defined options. Therefore, this field type is completely inappropriate for this requirement.

Set the field as 'Required' on the Page Layout.

Why it fails: Page layout requirements are only enforced when editing via the user interface. They can be bypassed by APIs or automated processes. Setting a field as 'Always Required' at the field level is a more robust solution because it ensures data integrity regardless of how the record is updated.

Create a Validation Rule that checks for ISBLANK.

Why it fails: While a validation rule works, it is technically less efficient than using the built-in 'Always Required' property on the field. Validation rules are best reserved for complex conditional logic that cannot be satisfied by standard system settings. Using them for simple requirements creates unnecessary configuration complexity for administrators to manage.

Use a default value.

Why it fails: A default value populates the field with initial information, but it does not prevent a user from clearing that value before saving the record. If the requirement is that the field must *always* contain a value, then setting a default is not a substitute for enforcing a required constraint.

Object-level sharing rules.

Why it fails: Sharing rules are part of the security model and are configured in the Sharing Settings section of Setup, not in the App Builder. The App Builder is exclusively for UI layout and presentation, and it does not have any role in defining the data access or security permissions for users.

Field-level security.

Why it fails: Field-level security is configured via the Object Manager or Profiles/Permission Sets. It controls data access at the database level. The App Builder cannot override or define security permissions; it only manages the presentation layer of the Lightning page, not the underlying authorization to access the specific field data.

Org-wide default settings.

Why it fails: Org-wide defaults (OWDs) are a fundamental part of Salesforce's security architecture, configured under Sharing Settings. They dictate the baseline access levels for data across the entire organization. They are not configurable within the Lightning App Builder, which has no influence over how the platform handles data security across users.

Use ISNEW() combined with PRIORVALUE() to detect modifications during updates

Why it fails: ISNEW checks if the record is being created for the very first time in the current transaction, returning true only on insert. Because this business requirement targets existing records that are being edited after reaching a specific stage, ISNEW will fail to trigger.

Use VLOOKUP() to cross-reference an external validation matrix table for stage constraints

Why it fails: VLOOKUP is intended for looking up values on related records across different custom objects based on matching criteria. It is not designed to compare the previous and current states of a single field on the same record during an update transaction.

Use PRIORVALUE() alone to compare current field values against historical audit logs

Why it fails: PRIORVALUE returns the previous value of a field, but using it by itself without ISCHANGED will cause the validation rule to evaluate incorrectly on every single save operation. It must be paired with a change detection function to properly isolate the exact moment of modification.

Global picklist dependency matrices configured at the object manager level

Why it fails: Global picklist dependency matrices control the filtering behavior between controlling and dependent picklist fields on data entry forms. They have no operational role in controlling the display logic or visibility of user interface components inside the Lightning App Builder.

Custom page layouts assigned exclusively through permission set licenses

Why it fails: Page layout assignments are managed via profile or record type associations rather than permission set licenses. Furthermore, page layouts dictate field arrangement, whereas component visibility controls are handled directly within the Lightning App Builder interface.

Profile-based application menu overrides for standard navigation tabs

Why it fails: Application menu overrides manage the visibility and ordering of navigation items within the global Salesforce navigation bar. They do not provide the granular component-level filtering capabilities required to customize individual record detail pages.

Rich text components do not support visibility filters tied to standard currency or numeric fields.

Why it fails: Rich text components fully support conditional visibility filters based on standard and custom fields of various data types, including currency and numeric fields. The issue stems from filter evaluation logic regarding null values rather than component incompatibility.

Annual Revenue evaluates as zero when blank, which satisfies the greater-than criteria in the filter logic.

Why it fails: Salesforce numeric and currency fields typically treat blank entries as null rather than zero, but certain UI filter evaluations can incorrectly process null states. To resolve this, the administrator must add an explicit ISBLANK or not-equal-to-null check in the filter configuration.

Lightning record page filters require a companion validation rule on the underlying object schema.

Why it fails: Lightning page visibility filters operate entirely within the client-side user interface framework and do not require backend validation rules to function correctly. Page layout performance and visibility rendering are managed independently of database validation logic.

The component visibility filter evaluates multi-currency conversions incorrectly when the user locale differs.

Why it fails: Multi-currency exchange rates affect reporting and displayed currency values, but they do not alter the fundamental evaluation of standard numeric threshold comparisons in client-side component visibility filters. The unexpected visibility is strictly related to null handling.

Delete the standard object from the organization.

Why it fails: Standard objects, such as Accounts, Contacts, or Opportunities, are integral components of the Salesforce platform. As such, they cannot be deleted by administrators. Attempting to remove core functionality would break systemic relationships and dependencies, which is why the platform prevents their removal via the standard Object Manager interface.

Change the data type of a standard field.

Why it fails: Standard fields have fixed data types that cannot be modified by the administrator. For example, an Email field cannot be converted into a Text Area field. This restriction is in place to maintain the integrity of standard features and integrations that rely on the specific format of these fields.

Remove the standard object from the Object Manager list.

Why it fails: The Object Manager displays all objects available in the organization, including all standard objects. There is no functionality to hide or remove these items from the list view. This provides a consistent management experience where all metadata objects are centralized for easy access and configuration by the administrator.

Validation Rule

Why it fails: Validation rules provide flexible logic but can be bypassed by certain integrations or API calls if not configured carefully. While they check data, they are technically metadata-based checks rather than structural database constraints like field-level requirements which trigger before the database DML process executes for all record types.

Lightning Page Component Visibility

Why it fails: Component visibility settings only control the rendering of UI elements on a Lightning record page. They do not prevent a user from saving a record without the field populated via other means like Data Loader or Quick Actions, making this an ineffective tool for enforcing mandatory data requirements.

Lookup Filter

Why it fails: Lookup filters are used to restrict the valid results in a lookup field based on criteria. They do not enforce that a field must be populated; they only define the subset of records that can be selected when the user decides to populate that specific relationship field.

Create a formula field on Case that references Account.BillingCity, then add it to the Case highlights panel through the page layout.

Why it fails: Cross-object formulas only traverse lookup relationships, and Case's Account relationship is a lookup, so a formula could technically be built, but the highlights panel is driven by the page layout's highlights panel section, and adding a formula there still requires layout and page work. More importantly, this duplicates data via a formula when the Related Record component already displays the live value, making it an unnecessary and less maintainable solution.

Edit the Case page in Lightning App Builder, add a Fields component, and configure it to display the Account's Billing City field.

Why it fails: A Fields component on a Lightning record page is bound to the page's primary record, so it can only surface fields that exist on the Case object itself. Billing City lives on the related Account, so the component cannot reach across the relationship to display it. This approach fails because the field is not on the Case record, regardless of how the component is configured.

Edit the Case page in Lightning App Builder and add a Rich Text component that hard-codes the Account's Billing City as static text.

Why it fails: A Rich Text component renders static content authored at design time; it cannot bind to a record's field value or update as the Account changes. Hard-coding the city would display stale, incorrect information whenever the Account's billing address changes. This approach also fails the requirement of showing the actual field value for the current record.

Hierarchical Relationship to User

Why it fails: A Hierarchical Relationship is a special lookup only available on the User object for building management chains. It cannot relate a custom object to an Account, so it fails the requirement entirely. This field type is reserved for user hierarchy scenarios such as reporting on managers and subordinates, not for linking business records to Accounts.

External Lookup Relationship to Account

Why it fails: An External Lookup Relationship points to an object stored outside Salesforce, such as an external data source object. It cannot establish a native parent-child link to the standard Account object, so no standard related list appears on the Account page. This field type is used for Salesforce Connect integrations, not for internal Account relationships.

Lookup Relationship to Account

Why it fails: A Lookup Relationship to Account also creates a one-to-many link and a related list, but the field is optional by default and does not enforce that each Vendor Invoice has exactly one Account. The requirement specifies that each Vendor Invoice must relate to exactly one Account, so the optional nature of a lookup makes it incorrect here.

Record Detail component

Why it fails: The Record Detail component shows the fields of the current record being viewed, not related records. On an Account page, it would display Account fields, not Project__c records. It does not support listing child records or creating them, making it unsuitable for this scenario.

Related Record component

Why it fails: The Related Record component displays fields from a single related record, not a list. It is used to show details of one parent record on a child record page, such as showing Account details on an Opportunity page. It does not provide a list of multiple related records or a way to create new ones, so it fails this requirement.

Dynamic Related List – Single component

Why it fails: The Dynamic Related List – Single component filters related records based on criteria but does not allow creating new records directly from the list. It is designed for filtered views, not for quick creation. Since the requirement includes creating a new Project__c, this component does not fully satisfy the need.

Create a validation rule on Supplier__c that prevents Standard User from editing 'Internal Rating'.

Why it fails: A validation rule can block a save when a condition is met, but it cannot hide a field from view. Reps would still see 'Internal Rating' on the page, and they could attempt to edit it, only to receive an error on save. The requirement is to prevent visibility, not to enforce data integrity at save time, so a validation rule does not satisfy the scenario and would create a poor user experience.

Change the field-level security for 'Internal Rating' to Hidden for the Standard User profile, and leave the page layout unchanged.

Why it fails: Setting field-level security to Hidden for Standard User would indeed hide the field from reps, but it also removes the field from reports, list views, and API access for that profile. The requirement is only to hide it on the record page while retaining editability for the operations team. This approach changes global field access rather than page visibility, and it does not leverage the page layout that already controls what appears on the detail page.

Create a permission set that grants edit access to 'Preferred Carrier' and assign it to the Standard User profile.

Why it fails: A permission set grants additional access; it does not remove visibility. Since 'Internal Rating' is already visible to Standard User through field-level security, adding a permission set would not hide it. This option also does not address the page layout, which is the mechanism that determines which fields appear on the record detail page. It would leave the visibility problem unresolved.

Lookup Relationship field

Why it fails: A Lookup Relationship field on Shipment__c would create a link to a single related record, not count multiple child records. It does not aggregate or display a total number of related Package__c records. This field type is used to establish a relationship, not to summarize child data.

Roll-Up Summary field

Why it fails: Roll-Up Summary fields can only summarize child records when the relationship is a master-detail relationship. A custom object related through a lookup relationship cannot be summarized with this field type. Since the scenario does not specify a master-detail relationship, this field type is not guaranteed to work and is therefore incorrect for the requirement.

Formula field with a COUNT function

Why it fails: Formula fields cannot reference child records directly; they can only reference fields on the same record or parent records via lookup. A COUNT function in a formula field is not available for counting related child records. This field type cannot dynamically display the number of child Package__c records on the Shipment detail page.