One Tutoring Calendar Across Salesforce and TeachWorks

#The starting position

Tutoring runs on the calendar. Every week, coordinators match students with tutors, schedule sessions around school timetables and family commitments, rearrange them when someone is sick, and make sure families receive a report on what each session covered. When the calendar is right, the business runs smoothly. When it is wrong, a tutor arrives at an empty house or a family waits for a tutor who is not coming.

The provider in this engagement delivers one-to-one tutoring through a team of tutors. It used two systems. TeachWorks, a platform built for tutoring businesses, handled appointments, attendance and session details. Salesforce held the relationship with families and the business view of the operation. Inside Salesforce, appointments appeared as a list, which made it hard to see a week at a glance.

The two systems did not talk. Coordinators entered sessions in one and then the other. Attendance and completion recorded in TeachWorks did not reach Salesforce. Session notes written by tutors had to be carried across by hand before they could go into the after-session reports families receive. Every manual copy was time lost and a chance for the two systems to disagree about what had happened.

The goal was one consistent scheduling view and an end to duplicate appointment administration.

#What we designed

01 A custom session calendar in Salesforce

We replaced the appointment list with a custom calendar view in Salesforce. Coordinators see sessions laid out by day and week, with tutors and students visible at a glance, so planning a week, spotting a clash or finding a free slot is a matter of looking instead of filtering a list.

02 Two-way appointment sync with TeachWorks

The integration architecture synchronizes appointments in both directions through the TeachWorks API. A session created or changed in Salesforce is created or updated in TeachWorks, and changes made in TeachWorks come back to Salesforce. Coordinators can work in whichever system suits the task, and both stay current.

03 Attendance and completion mapping

After a session, attendance and completion status recorded in TeachWorks are mapped back to Salesforce. The mapping was defined carefully, because the two systems use slightly different meanings for statuses such as cancelled, missed and completed, and a wrong mapping would quietly distort the business view.

04 Session notes into after-session reports

Tutors' session report notes are mapped into Salesforce, where they feed the after-session reports. The provider already had an admin approval and PDF process for those reports, and the design works with that process, so reports are still checked before they reach families.

05 A safe path to production

The work follows a sandbox, user acceptance testing and deployment workflow agreed in the project discussions, so the calendar and the sync are proven against real sessions before coordinators rely on them.

#A week in the coordinator's chair

On Monday morning a coordinator opens the calendar in Salesforce and sees the week: every tutor, every student, every session. A parent calls to move Thursday's session to Friday. The coordinator moves it to the new slot, and the change reaches TeachWorks, where the tutor sees it.

On Thursday a tutor marks a session complete in TeachWorks and writes notes on what the student covered. That status and those notes return to Salesforce without anyone copying them. The after-session report is assembled from the notes, goes through the usual admin approval, and is sent to the family as a PDF.

At the end of the week, the business view in Salesforce shows sessions held, missed and completed, because attendance arrived from the system where it was recorded.

#Why integration beats replacement here

It is tempting to solve a two-system problem by removing one system. In this case that would have been a mistake. TeachWorks is designed around the details of running tutoring sessions, and the team uses it well. Salesforce is where the provider manages relationships with families and runs the business. Each is better at its own job than the other would be.

The real problem was not having two systems. It was having two systems that did not agree. A well-designed sync keeps both, removes the duplicate entry and makes sure each piece of information has one owner: the booking, the attendance and the notes each originate in a defined place and are reflected everywhere else.

That is also the more affordable path. Replacing a working operational platform means retraining the team, migrating history and rebuilding features that already exist. Connecting it to Salesforce costs a fraction of that and leaves the team with tools they already know.

#Designing a two-way sync that does not fight itself

Two-way synchronization is one of the most common integration requests and one of the easiest to get wrong. When both systems can change the same record, a careless design creates loops, where an update from one side triggers an update back, or overwrites, where an older version of a session replaces a newer one.

The design avoids those problems with a few rules.

Every session has a shared identifier. When an appointment is created in either system, the identifier from the other system is stored against it. Updates always find the right partner record instead of creating duplicates.

Changes carry their origin. An update that arrived from TeachWorks is not sent back to TeachWorks. Recording where a change came from is what stops loops.

Each field has an owner. Booking details can change on either side, but attendance and completion come from TeachWorks, where the session is run, and are never overwritten by Salesforce. Notes come from the tutor and are mapped into Salesforce for reporting.

Failures are visible. If a sync cannot complete, because a record is missing or the platform is temporarily unavailable, the problem needs to be visible to an administrator instead of silently dropped, so it can be retried or corrected.

These rules are not specific to tutoring. They apply to any business that wants two operational systems to agree, and they are the difference between a sync that the team trusts and one it learns to double-check.

#How we delivered it, end to end

Map the session lifecycle. We started by writing down every step of a session, from booking to report, and which system each step happens in.

Decide the owner of each field. Booking details, attendance, completion and notes each have a defined source, which prevents the sync from overwriting good data with stale data.

Design the calendar around the coordinator. The calendar view was shaped by how coordinators plan a week, not by how records are stored.

Fit into the approval process. The report notes feed the existing admin approval and PDF workflow instead of creating a new one.

Prove it before relying on it. Sandbox, user acceptance testing and deployment steps were planned so that each part is tested with real sessions.

#The decisions that mattered

Keep both systems. Integrating instead of replacing preserved the tools the team uses well.

Calendar over list. A visual week is how tutoring businesses think, so the main interface follows it.

Precise status mapping. Defining exactly how attendance and completion translate between systems protects the accuracy of every report built on them.

#What changed

#What we would tell a tutoring business starting this

Before you change any system, decide where each part of a session is created and owned: the booking, the attendance and the notes. Then connect your systems so that each piece is entered once and visible everywhere it is needed. Give coordinators a calendar, because that is how they think, and keep any approval step that protects families from mistakes.