validateDomainProcessBindings
Call Signature
Section titled “Call Signature”validateDomainProcessBindings(
scan):DomainProcessBindingIssue[]
Defined in: packages/simply-aep-core/src/at4dxDomainProcessResolve.ts:172
Validate a scan’s DomainProcessBinding__mdt records for wiring problems resolveDomainProcessBindings/
list don’t fail on: order collisions (reused from resolveDomainProcessBindings), records with no
resolvable SObject, bindings whose declared processContext doesn’t match the field that’s actually
populated (dead — never matches any real execution), duplicate DeveloperNames across everything
scanned, an ambiguous SObject reference (both fields set to different values), the primary field set to
a standard object that can’t actually go through EntityDefinition, and the Alternate field set to an
object that didn’t need it.
Every issue is stamped with the scope its rule declares in DOMAIN_PROCESS_BINDING_RULES
('record' or 'scan') — see docs/design/0011-domain-process-binding-issue-scoping.md. This
function always validates every record passed in; a caller that wants a scoped view of the result
calls filterDomainProcessBindingIssues on the returned issues afterward, rather than filtering
records first, which would silently break duplicate-developer-name.
See docs/design/0010-at4dx-domain-process-binding-validate.md for the full rationale behind the first five rules, and docs/design/0014-domain-process-binding-entity-definition-eligibility.md for the EntityDefinition-eligibility pair.
Parameters
Section titled “Parameters”Pick<DomainProcessLocalScanResult, "records" | "malformed" | "ambiguous">
Returns
Section titled “Returns”One issue per problem found. Empty when nothing’s wrong.
Call Signature
Section titled “Call Signature”validateDomainProcessBindings(
records,diagnostics):DomainProcessBindingIssue[]
Defined in: packages/simply-aep-core/src/at4dxDomainProcessResolve.ts:175
Validate a scan’s DomainProcessBinding__mdt records for wiring problems resolveDomainProcessBindings/
list don’t fail on: order collisions (reused from resolveDomainProcessBindings), records with no
resolvable SObject, bindings whose declared processContext doesn’t match the field that’s actually
populated (dead — never matches any real execution), duplicate DeveloperNames across everything
scanned, an ambiguous SObject reference (both fields set to different values), the primary field set to
a standard object that can’t actually go through EntityDefinition, and the Alternate field set to an
object that didn’t need it.
Every issue is stamped with the scope its rule declares in DOMAIN_PROCESS_BINDING_RULES
('record' or 'scan') — see docs/design/0011-domain-process-binding-issue-scoping.md. This
function always validates every record passed in; a caller that wants a scoped view of the result
calls filterDomainProcessBindingIssues on the returned issues afterward, rather than filtering
records first, which would silently break duplicate-developer-name.
See docs/design/0010-at4dx-domain-process-binding-validate.md for the full rationale behind the first five rules, and docs/design/0014-domain-process-binding-entity-definition-eligibility.md for the EntityDefinition-eligibility pair.
Parameters
Section titled “Parameters”records
Section titled “records”RawDomainProcessBindingRecord[]
diagnostics
Section titled “diagnostics”The malformed/ambiguous records the same scan reported alongside records. Omitted when the first argument is already a scan envelope.
ambiguous
Section titled “ambiguous”AmbiguousDomainProcessBindingRecord[]
malformed
Section titled “malformed”MalformedDomainProcessBindingRecord[]
Returns
Section titled “Returns”One issue per problem found. Empty when nothing’s wrong.