Parent-Child Record Archival
Overview
AutoRABIT Vault ensures data integrity when archiving records in Salesforce by automatically including certain child records based on specific relationship criteria. This FAQ explains the scenarios where child records are considered mandatory for archival.
Parent-Child Record Archival
It is important to archive both parent and child records together. This ensures that:
No orphaned records are left behind.
Data integrity is maintained.
Salesforce restrictions and relationships remain consistent.
Compliance and audit requirements are met.
Mandatory Child Record Archival Criteria
AutoRABIT Vault analyzes Salesforce relationship configurations and automatically considers a child record mandatory for archival if it meets any of the following criteria:
It has a Master-Detail Relationship with the parent.
It is linked through a Required Lookup Relationship enforcing dependency.
It is configured for Cascade Delete, meaning it is deleted when the parent is deleted.
The parent deletion is prevented due to a Restrict Parent Deletion rule. The parent record cannot be deleted unless the child is removed, necessitating their joint archival.
This process ensures a seamless and compliant archival strategy.
Master-Detail Relationships
A Master-Detail Relationship means that child records are inherently dependent on the parent. When a parent record is archived, all related child records must also be archived. Example: Invoice & Invoice Line Items – When an Invoice is archived, all related Invoice Line Items are archived automatically.
Required Lookup Relationships
In Salesforce, a Lookup Relationship typically allows a child record to exist independently. However, if the lookup field is marked as required, the child record must always have a parent, mimicking a Master-Detail Relationship. When the parent is archived, the child is also archived to maintain data integrity. This is commonly found in custom objects where the lookup field is set as required, ensuring that every child record is always linked to a parent record.
Cascade Delete
Cascade Delete is a Salesforce setting where deleting a parent record automatically deletes all associated child records. AutoRABIT Vault ensures these child records are archived along with the parent instead of being deleted. For example, Account & Contacts – If an Account is archived, all related Contacts are archived to maintain consistency.
Parent-Child Restrict Deletion
Salesforce enforces a rule preventing a parent record from being deleted if it has associated child records. If a parent record with a restrict deletion rule is archived without its associated child, Salesforce enforces the restriction, meaning the archival process would fail unless the child records are also archived. AutoRABIT Vault ensures these relationships are accounted for automatically.
When archiving such a parent record, the child must also be archived to comply with Salesforce restrictions; otherwise, the archival will fail. For example: Contacts and Cases – A Contact cannot be deleted if it has associated cases. Archiving the Contact requires archiving its related Cases as well.
Configuring a Lookup Relationship Like a Master-Detail Relationship
By marking the lookup field as required, you can enforce a dependency similar to a Master-Detail Relationship. This ensures that the child always references a valid parent, making its archival necessary when the parent is archived.
Email Messages Relationships
Email messages are mandatory child records for objects to which the email messages hold a direct relationship. Email messages will hold direct relationship to the following objects through the fields ‘RelatedToId’ and the ‘ParentId’:
Account Accreditation AssessmentIndicatorDefinition AssessmentTask AssessmentTaskContentDocument AssessmentTaskDefinition AssessmentTaskOrder Asset AssetRelationship AssignedResource Award BoardCertification BusinessLicense BusinessMilestone BusinessProfile Campaign CareBarrier CareBarrierDeterminant CareBarrierType CareDeterminant CareDeterminantType CareDiagnosis CareInterventionType CareMetricTarget CareObservation CareObservationComponent CarePgmProvHealthcareProvider CarePreauth CarePreauthItem CareProgram CareProgramCampaign CareProgramEligibilityRule CareProgramEnrollee CareProgramEnrolleeProduct CareProgramEnrollmentCard CareProgramGoalCareProgramProduct CareProgramProvider CareProgramTeamMember CareProviderAdverseAction CareProviderFacilitySpecialty CareProviderSearchableField CareRegisteredDevice CareRequest CareRequestDrug CareRequestExtension CareRequestItem CareSpecialty CareSpecialtyTaxonomy CareTaxonomy Case CommSubscriptionConsent ContactEncounter ContactEncounterParticipant
ContactRequest Contract CoverageBenefit CoverageBenefitItem CreditMemo DelegatedAccount DocumentChecklistItem EnrollmentEligibilityCriteria HealthcareFacility HealthcareFacilityNetwork HealthcarePayerNetwork HealthcarePractitionerFacility HealthcareProvider HealthcareProviderNpi HealthcareProviderSpecialty HealthcareProviderTaxonomy IdentityDocument
Image IndividualApplication Invoice ListEmail Location MemberPlan Opportunity Order OtherComponentTask PartyConsent PersonLifeEvent PlanBenefit PlanBenefitItem ProcessException Product2 ProductItem ProductRequest ProductRequestLineItem ProductTransfer PurchaserPlan ReceivedDocument ResourceAbsence ReturnOrder ReturnOrderLineItem ServiceAppointment ServiceResource Shift Shipment ShipmentItem Solution Visit VisitedParty VolunteerProject WorkOrder WorkOrderLineItem
If an object has a reference from another object as both parent and child, then the parent will only be considered for a backup but not for archival. The child records will only be considered for archival.
Last updated
Was this helpful?