Plauti Verify ships the same phone, email, and address validation fields that you use inside a screen flow as standalone Lightning Web Components. Because they are exposed in the managed package, you can place them on any record page — without building an entry form or a flow.

On their own, these components only validate what the user types. They do not read a field from the record and they do not save anything back. To turn them into an inline editor, you wrap the Verify component in a small custom LWC of your own that adds three things:

• Record binding — read the current field value with getRecord from lightning/uiRecordApi.
• An edit toggle — show a read-only value until the user clicks edit, then render the Verify component.
• Save on a good result — write the validated value back with updateRecord, only when validation passes.

This is the recommended pattern for the common request: "I want the Verify validation experience directly on my Account or Contact page, not behind an entry form."

The Verify components

All three are exposed to lightning__RecordPage, lightning__AppPage, and lightning__HomePage, and can be referenced from your own LWC markup using the recordval namespace prefix. Referencing them from your own component is cross-namespace usage, which requires Lightning Web Security — see Before you start.

The advice value

Every Verify component reports the outcome of a validation through an advice value. This is the signal you use to decide whether a value is safe to save.

The components also emit a validated event once the Verify API responds. The event detail carries the advice, the corrected value, a statusCode, and a human-readable message. The examples in this section block the save action unless advice is GREEN. You can relax this to also accept AMBER if your data quality policy allows it.

📘

The examples are unstyled

The Verify components render with their own internal styling, but the wrapper markup in these examples is intentionally minimal. The read-only view, edit toggle, and buttons carry no layout or spacing. Apply your own SLDS utility classes and layout so the component matches the rest of your record page before using it in production.

Before you start

• Lightning Web Security (LWS) must be enabled in the org — it is required to reference a managed-package LWC from your own component (see the note below).
• The Verify managed package (recordval) must be installed and licensed in the org.
• The user needs access to the Verify validation Apex services, the same as when using the screen flow components.
• Each validation consumes credit, exactly as it does in a flow.

🚧

Lightning Web Security is mandatory for cross-namespace use

Placing a managed-package Lightning web component inside your own component is cross-namespace composition, which Salesforce only permits when Lightning Web Security (LWS) is enabled for the org (Setup → Session Settings → Use Lightning Web Security for Lightning web components). This is required even though the Verify components are globally exposed — being globally accessible is not enough on its own. With the older Lightning Locker, referencing recordval-rv2-*-component from your own LWC is blocked, and the wrappers in this section will not work.

Next steps

• Inline validate a phone field
• Inline validate an address
• Inline validate an email field