An Attendance Interval Lost Its Attendee Link: Restore Participant Attribution

An attendance interval has lost its attendee link when a join and leave record still exists, but the system can no longer prove which participant record owns it. Treat the interval as intact evidence, not as a damaged contact record.

The repair is a controlled attribution decision. First preserve the original provider evidence. Then identify the possible participant records, state the edge that should exist, record what remains blocked, and require approval before writing the correction.

Who owns an intact orphaned attendance interval?

No one owns it yet. The interval is owned by its source record until evidence supports a specific participant-to-interval edge. A person who joined from multiple devices or rejoined later can have more than one session, so one time range alone is not enough to assign attendance.

Google Meet documents a participant session as a unique join or leave session. Each time a user joins a conference, a new unique session ID is assigned, including when the same person joins again from the same device. Microsoft Graph attendance records can also contain identity details. They can include an email address, role, total attendance, and one or more attendance intervals.

Which provider evidence should you preserve first?

Capture the provider's stable identifiers before data maintenance or attendance editing. Keep the raw response or event payload in a restricted audit store, then write a pointer to it in the attribution ledger.

For Google Meet, retain the conference record, participant resource name, participant session resource name, and session start and end times. Google Meet states that participant sessions have their own IDs and timestamps. For Microsoft Graph, retain the meeting ID, attendance report ID, attendance record identity fields, and each interval. For Amazon Chime SDK media capture pipelines, retain the event's timestamp and type, along with its parameters from the meeting event file.

• Record the source system and source retrieval time.
• Keep the unmodified provider identifiers and timestamps.
• Store candidate matches separately from confirmed matches.
• Do not replace a missing attendee link with a display-name match.

How do you test candidate participant IDs without guessing?

Build candidates from evidence already attached to the same provider record. A candidate can be supported by a stable provider participant ID, an authenticated identity field, an attendance-report identity, or a provider session path. A display name can help a reviewer investigate, but it does not settle attribution by itself.

Compare the expected relationship against the provider model. Google Meet distinguishes a participant resource from participant sessions, and says a participant session is tied to a participant-device join. Microsoft Graph's attendance record example keeps attendance intervals inside the attendance record that also carries identity and role fields. If the available evidence cannot establish that relationship, leave the interval orphaned.

• Rank candidates by direct provider identifiers before names or time proximity.
• Reject candidates that require inferred emails or reused display names, as well as unrelated CRM activity.

• Mark the candidate set as unresolved when more than one record remains plausible.
• Attach the reviewer decision to the exact interval ID, not only to the meeting.

Which attendance, consent, and CRM decisions remain blocked?

Identity-dependent decisions remain blocked until approval. That includes adding attendance to a person record, changing a lifecycle stage, creating a sales task from attendance, calculating participant-level attendance totals, and assigning campaign or meeting attribution.

Consent remains separate from attendance. An orphaned interval does not establish that the person can be contacted for marketing. Do not create or update consent from a candidate match. If a valid consent record already exists, keep it unchanged unless the correction process has evidence for a permitted update.

• Block participant-level CRM writes.
• Block attendance-triggered outreach and automation.
• Block participant-level reporting and conversion attribution.
• Allow only aggregate reporting when the report cannot identify or alter a person and the underlying governance permits it.

How should a reviewer approve the correction?

Use a two-part decision: evidence review, then write approval. The reviewer should see the raw provider evidence, the candidate participant IDs, the proposed edge, the blocked decisions, and any conflicting evidence. The reviewer either approves one explicit edge or rejects the match and keeps the interval unassigned.

After approval, write only the approved relationship. Preserve the raw interval and the prior orphaned state. Record who approved it, when they approved it, the provider evidence reference, and the correction ID. A later reconciliation should be able to reproduce why the edge exists without relying on a changed contact profile.

• Create a correction record before changing the attendance relationship.
• Require an approver who can assess the provider evidence and CRM identity rules.
• Write the expected participant-to-interval edge only after approval.
• Re-run blocked automations only if their own rules permit a corrected historical event.

What should happen when evidence still does not identify the attendee?

Keep the interval unassigned. Close the repair as unresolved, record why the candidates failed, and retain the evidence for later reconciliation under the applicable retention rules.

Do not force a CRM contact or infer consent; do not silently drop the interval. A clean unresolved state is more accurate than an attribution edge that cannot be defended.