Either of the following 2 workarounds should solve your problem.
Option 1:
In the component, (within the lightning-record-* HTML) include the field (that's not a part of the object's page layout) inside a conditional template using lightning-output-field
<template if:true={showCustomField}>
<lightning-output-field field-name="<custom field api name here>"></lightning-output-field>
</template>
In the JS file, declare a boolean with default value as true (this will be used in the template conditional logic of HTML file). If you don't want to display the field in the component, you can toggle it in the load event handler of the record view form. If you examine the payload in the load handler (see the console.log in code snippet below), you'll find the field value included as a part of the payload.
showCustomField = true;
// Event handler wired to the load event of record view form
loadHandler(event){
console.log(JSON.parse(JSON.stringify(e.detail.records[this.recordId].fields)));
this.showCustomField = false;
}
Option 2:
In the JS file,
- include LDS & wire service to get the record data
- use getter to fetch the value of the field (the one that is not included in the page layout) in the
load event handler.
This would mean an extra server call (the one invoked using wire service, in addition to call invoked implicitly by lightning-record-* component) to get specific fields that you need. Sample code snippet is given below using Account object. The wire service executes before loadHandler and hence, you will have the required fields upfront. Now, inside the loadHandler, you can use the getter to access the field values. Since, you have both the payload and additional field info during the execution of the load event handler, you should be able to write code to implement anything you want. Note that this snippet gives only the relevant code and you should include it (or tweak it) appropriately in your component. See inline comments for additional explanation.
import { getRecord, getFieldValue } from 'lightning/uiRecordApi';
import ACCOUNT_OBJECT from '@salesforce/schema/Account';
// Following line is import of the field that is not included in the page layout. Edit this line of code appropriately
import CUSTOMFIELD_FIELD from '@salesforce/schema/Account.<Replace API Name of the Custom Field here>';
@api recordId;
@api objectApiName;
objectApiName = ACCOUNT_OBJECT;
@wire(getRecord, { recordId: "$recordId", fields: [CUSTOMFIELD_FIELD]})
record;
get customField() {
return this.record.data ? getFieldValue(this.record.data, CUSTOMFIELD_FIELD): "";
}
// Event handler wired to the load event of record view form
loadHandler(event){
// lightning data service is implicitly used to fetch the required details for the record view form.
// Use event.detail to get all that you need.
// Using getter, fetch the value of required fields that were not found in event.detail.
console.log(this.customField);
}
Best Answer
@keith-c is right that the layouts work in combination with the field security set in the profile. The use case for that is two users with different profiles who share the same layout. One profile can access Field A while the other profile cannot. In this case, you don't have to build two different layouts.
If you're wanting to do this exclusively through the Metadata API, you'd need to also deploy modified versions of all your profiles which include the new field's visibility settings.
Here's an example of the elements you'd need in the profile:
Note that it's probably a good idea to retrieve the profiles first before editing them. If you are working with an older copy of the profile on disk you might wind up deploying the older version and overwriting other changes made to the profile.
Here's the relevant Metadata API docs: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_profile.htm#profilefieldlevelsecurity_title