Google, iCloud and the CRM Calendar: What Syncs, What Deletes, and Who Gets Reminded
Most small firms already have a calendar. They usually have two: the one on the phone and the one somebody made in the CRM, and between them sits a person who copies meetings from one to the other on Monday morning. Firmspace does not ask anyone to give up the phone calendar. It connects it — Google and iCloud — and then has to answer a harder question than import: what happens when the same meeting is edited in two places, and who is told about it.
The external calendars are connected in the sync panel of the calendar section, which lives in Collaboration next to chat and mail. Google connects through a normal sign-in, the same kind of consent screen as for mail or Drive. iCloud cannot do that: Apple has no OAuth for calendars, so it asks for an Apple ID and an app-specific password. That difference is not cosmetic; it decides what the connection is allowed to do.
Google is a two-way connection. Events created in the CRM are written into the calendar chosen in the settings, or into the primary one if no choice was made — and if the chosen calendar later disappears from Google, the write goes back to the primary instead of failing silently. Edits and deletions travel the same way. One exception is deliberate: an event marked as personal is never pushed. A company Google calendar may be visible to colleagues, and a private appointment has no business appearing there.
iCloud is read-only, and the interface says so instead of pretending. Apple does not allow writing without an app password for every action, so events from Apple arrive in the CRM, but an edit made there stays in the CRM only — and the next sync puts the Apple version back. When someone edits an iCloud event, the CRM shows a warning with exactly that wording. It is better to disappoint immediately than to show a green checkmark for a change that will vanish by the evening.
Every imported event is remembered by two things together: the provider it came from and its identifier there. That pair is what prevents the most common failure of every calendar integration — the same meeting appearing twice after two syncs. A repeated sync finds the existing row and updates it; it does not create a twin. The meeting can be moved, renamed or given a new time in Google as often as the team likes, and the CRM still holds one event, not eleven.
Deletion is the part that scares people, so the rules are narrower than they look. A sync only removes an event if three conditions hold at once: it lies inside the synchronised window of one month back and six months ahead, it belongs to a calendar that was actually read in this pass, and it has genuinely disappeared at the provider. Events from a calendar that was switched off are not deleted. Turning off the sync is not the same as saying the events never happened.
Three things the provider is not allowed to overwrite. The colour of an event created in the CRM stays the one a person chose; the provider colour applies only to events imported for the first time, which is why Google events arrive blue and iCloud ones arrive violet. The calendar an event belongs to stays as chosen inside the CRM. And the time-zone offset of an event is replaced only when the provider actually sends one — otherwise a note about a call at nine would quietly shift by an hour.
There is no separate schedule for syncing. It is driven by the same five-minute sweep as the other background work, and, while somebody has the CRM open, by the notification poll that runs every thirty seconds. Inside, a fifteen-minute pause keeps Google and Apple from being asked on every poll. The practical effect: a meeting added on the phone shows up in the CRM within minutes, and nobody had to press a sync button.
Failures are handled per provider, not for the whole feature. If Google refuses — an expired token, a revoked permission — the connection is marked as broken and the panel offers to reconnect, because a connection that silently stopped is worse than one that says it stopped. If iCloud refuses only some calendars, that is a warning, not a failure: the rest keep syncing and the reason is shown in the settings. One provider being down never stops the other.
Reminders are the reason the calendar is opened at all. An event can carry a reminder of five, fifteen, thirty or sixty minutes before the start. The notification itself is produced by Firmspace, not by Google or Apple, and it lands where notifications usually land: in the bell inside the CRM, and in Telegram if the firm's notification bot is configured. The email copy goes to those who have email reminders switched on in their profile, provided the firm's mailbox is connected.
Time is stored as the wall-clock time of the person who created the event, not as an absolute moment. That is why a meeting at nine in Berlin stays at nine when somebody checks the CRM from Lisbon, and why the comparison for a reminder uses each event's own offset instead of the browser's. For events created before the offset was stored, the browser's offset is used as a fallback — a compromise that keeps old events working without silently moving them.
A reminder is not thrown away just because it is late. The window used to be five minutes, and a reminder missed because the CRM was closed was gone forever; now the upper bound is the end of the event, plus an hour for events without an end. A notification triggered by a repeated sweep is not created twice: its key includes the event, its start time and the reminder value, so the same nudge exists exactly once, no matter how many times the sweep runs.
Who receives the reminder follows the same split as the calendar itself. A personal event reminds only its author — it is their appointment, and the rest of the firm has no reason to know it exists. A company event reminds the firm, and the email copy goes out according to each person's own profile settings. This is one place where a notification setting matters more than the notification: a team that switched email reminders off should not be surprised by silence.
One limit has to be said plainly, because it decides whether the reminder can be trusted with something important. Times are checked only when the sweep runs: every five minutes by the server, or every thirty seconds while somebody has the CRM open. If nobody has it open and the server sweep is not running, a reminder arrives late — or not at all for an event that already ended. The calendar in a CRM is a working tool, not a pager. Everything else — the sync, the duplicates, the deletions, the time zones — is built so that this one honest limit is the only thing left to manage.