Scheduling contacts and meeting history

Short answer: Review relationship context and upcoming or completed meetings. Begin with “Search by the participant's stable email address.” and verify the result through the public participant path.

Before you change the setup

Identify the exact organizer, event type, public link, and time zone involved before editing anything. Save the current behavior or take a screenshot so the test has a reliable before-and-after comparison.

How to complete this task

Search by the participant's stable email address.Start with the intended outcome and the record that controls it.
Review future and past meetings before adding context.Review every related setting before saving so one rule does not mask another.
Record only useful, appropriate notes with a clear retention purpose.Keep private data and guest-facing information clearly separated.
Use the correct event type when inviting the contact again.Complete the same path an external participant will use.

Verify the participant result

Run one successful case and one edge case. Confirm the public title, local time, available choices, duration, location, confirmation, calendar file, and private management path as applicable. Then check the organizer view and any email delivery record. A saved setting is not proof that the scheduling lifecycle worked.

Troubleshoot scheduling contacts and meeting history

These are the failures reported most often for this specific task, with the cause that explains each one.

The same person appears twice.

Match on a stable email address. A personal address and a work address are two records unless you merge them deliberately.

Meeting history is missing.

History follows the address used at booking. If someone booked with a different address, the earlier meetings live on that record.

What should not be stored in a note?

Anything you would not show the contact. Keep notes to scheduling-relevant facts with a stated retention purpose.

Related Meetin.gs help

Return to the Meetin.gs Help Center for the adjacent configuration guide, or send the exact event code and expected result when the documented checks do not explain the behavior.

Scheduling contacts and meeting history acceptance checklist

Use the following evidence map while completing this specific task. It ties each action to an observable result so another person can repeat the setup or diagnose it without guessing.

1. Search by the participant's stable email address.

Write down the intended result, the organizer or account that owns it, and the exact event type or public link in scope. This prevents a correct change from being applied to the wrong record.

2. Review future and past meetings before adding context.

Inspect the related rules and dependencies before saving. Record the previous value and the new value, including the time zone, provider account, or team owner when one controls the outcome.

3. Record only useful, appropriate notes with a clear retention purpose.

Review what an invitee can see and what remains private. Keep only the context needed to complete the meeting task, and make the fallback understandable when information is missing.

4. Use the correct event type when inviting the contact again.

Complete this step from a signed-out participant session. Preserve the resulting URL or event code, displayed state, message, calendar output, and any provider response needed to prove the task worked.

Evidence type	What to record
Controlling input	The account, event type, setting, public link, and time zone used in the test.
Participant result	The exact choices, context, confirmation, or error visible while signed out.
Lifecycle result	What changes after confirmation, finalization, cancellation, reschedule, or retry.
Failure boundary	The missing permission, unavailable dependency, invalid input, or conflicting rule that prevents success.
Owner	The person responsible for correcting the setting, provider connection, content, or customer communication.

Evidence type

What to record

Controlling input

The account, event type, setting, public link, and time zone used in the test.

Participant result

The exact choices, context, confirmation, or error visible while signed out.

Lifecycle result

What changes after confirmation, finalization, cancellation, reschedule, or retry.

Failure boundary

The missing permission, unavailable dependency, invalid input, or conflicting rule that prevents success.

Owner

The person responsible for correcting the setting, provider connection, content, or customer communication.

RELATED CAPABILITY

Scheduling contacts

See the people you meet, their upcoming and past events, and the context needed for the next conversation. This page explains scheduling contacts requirements. Confirm production availability before depending on this capability.

Review scope

Scheduling contacts and meeting history: frequently asked questions

Short answers to the questions organizers ask most about scheduling contacts and meeting history.

What is a scheduling contact?

The person behind repeat bookings, identified by a stable email address, together with their meeting history and any notes you record.

Why does the same person appear twice?

They booked with two addresses. Match on a stable address and merge deliberately rather than by name, which is unreliable.

What should a contact note contain?

Scheduling-relevant facts only — preferred times, access needs, agreed follow-up. Write nothing you would not be comfortable showing the contact.

How long should meeting history be kept?

Keep it as long as it serves a stated purpose, then delete it. Retention without a purpose is a liability, not an asset.