How ERPNext connects to Google Calendar and Drive
A team that wants ERPNext events and backups to sit alongside Google Workspace should plan for OAuth 2.0 credentials created in Google Settings, which is the supported method for both the Google Calendar and Google Drive integrations. Calendar access is then authorized per user, so each person who wants their events synced grants access from their own ERPNext login. Drive is configured once for backups: after authorization, ERPNext uploads backups to a named Google Drive folder at the frequency you choose. Before scoping, confirm with the Google Cloud project owner which OAuth consent screen type, scopes and test or production status your Workspace domain requires, since those decisions sit outside ERPNext.
The Calendar integration works in both directions, pulling events from Google Calendar into ERPNext or pushing ERPNext events out, and you choose the direction per integration. Decide early which direction each team needs, because a two-way picture of meetings can duplicate or overwrite events if two systems are treated as the source of truth. Map which ERPNext events, such as project milestones or customer visits, should appear in shared calendars, and who owns the Google account whose calendar is connected. Staff who leave the organization should have their authorization revoked so their calendar stops syncing.
Google Contacts is not covered by a documented ERPNext connector in the supplied material, so do not assume contact sync exists. If your team needs customer or supplier contacts in Google Contacts, treat it as a custom build or a separate tool, and confirm the approach with DeployOpen or the ERPNext community before it enters a fixed-scope quote. Also confirm the exact ERPNext version and whether the Google settings screens differ on your release, since integrations can move between versions. A short proof of concept on a test site, with a test Google account and a sample folder, will show the sync behavior before production credentials are issued.
What you need before connecting ERPNext to Google
Four decisions and checks come before any Google connection is configured: the ERPNext version and hosting model, the Google Cloud credentials, the accounts that authorize access, and the network path back to your site. Each one can block the Calendar, Contacts or Drive work if it is left until the end.
Confirm the ERPNext version and support status
Start by recording the exact ERPNext and Frappe Framework version your site runs. Frappe's supported versions page lists which releases receive support, and version 14 reached end of life on January 31, 2026. Frappe's warranty coverage depends on running a listed version and holding a matching Frappe Cloud support plan, so confirm that status before you plan changes to a Google integration. Ask your partner or Frappe to confirm which versions your site can use.
Choose the hosting model
Decide whether the site runs on Frappe Cloud, on Docker Compose, or on a manual bench installation. The hosting model decides who can change outbound network rules, who holds the site's TLS certificate, and whether custom server-side code can run. Frappe Cloud public shared benches do not allow Server Scripts, so confirm that the Google sync you need does not depend on them.
Create a Google Cloud project with OAuth 2.0 credentials
Each Google service in ERPNext uses OAuth 2.0 credentials created in Google Settings. Create a Google Cloud project for the organization, enable the Calendar, People and Drive APIs your use case needs, and register the client ID and secret in ERPNext. Keep the OAuth consent screen and client owned by an organization account, not an individual's personal account, so the integration survives staff changes.
Map the Google accounts and ERPNext roles
Each sync runs against a specific Google account, and that account must authorize access before any events, contacts or backups move. List which Google users will connect Calendar and Contacts, and which account owns the Drive folder for backups. On the ERPNext side, confirm that the users who configure the integration hold the System Manager role or equivalent permissions, and that people who should not see other users' calendars are not granted access.
Verify outbound HTTPS and redirect reachability
The ERPNext server must reach Google's OAuth and API endpoints over outbound HTTPS, and Google must reach the redirect URL registered for your site. Check egress firewall rules, proxy settings and DNS for the site's public hostname. Confirm that the redirect URL in the Google Cloud client matches the site URL exactly, including the scheme and any path, because a mismatch stops the authorization step.
Plan the sync direction and backup ownership
Before enabling anything, decide what each integration may change. Calendar can pull from Google, push to Google, or be set per user, and a push can create entries in shared calendars. Drive stores backup files outside your infrastructure, so decide who may read that folder, how long backups are kept there, and who receives failure notices. Document these choices in the change record, since the Drive folder and calendar scope are the first things an auditor or data owner asks about.
Configuring Google Calendar sync step by step
This sequence takes a site from no Google connection to a working two-way calendar sync, with each user authorizing their own calendar. Each step ends with a check so the administrator knows which part is working before moving on.
Create OAuth 2.0 credentials in Google Cloud
In the Google Cloud Console, create or choose a project, enable the Google Calendar API, configure the OAuth consent screen for your organization, and create an OAuth client ID of the web application type. Set the authorized redirect URI to the callback address that the ERPNext Google Calendar documentation specifies for your site, and copy the client ID and client secret. Confirm the consent screen scopes include calendar access, since the sync cannot read or write events without it. Your Google Workspace administrator usually needs to approve this step, so confirm who holds that role before you start.
Enter credentials in Google Settings
In ERPNext, open the Google Settings single document from the search bar, tick the option to enable Google integration, and paste the client ID and client secret from the previous step. Save the document, then confirm the fields are stored and the client secret is no longer displayed in plain view. This step is done by a user with System Manager access, and it applies to the whole site rather than to individual users. A save with no error message is the signal that the settings are in place.
Enable the Google Calendar integration
Open Google Calendar Settings in ERPNext and enable the integration for the site. Choose the calendar behaviour you need at this stage, including whether ERPNext events should be pushed to Google, pulled from Google, or both. Save the record. Confirm the Google Calendar Settings record shows the integration as enabled and that no validation message appears. Keep the sync direction under review, because the choice affects which side can overwrite an event in the next steps.
Authorize calendar access for each user
Each user who wants a sync must open their own Google Calendar record in ERPNext, create the calendar link, and complete the Google sign-in and consent screen that appears. The user approves access to their own calendar, not to the company calendar of another person. Once Google redirects back to ERPNext, the Google Calendar record should show an authorized state and a sync token or equivalent status. An authorization that stays pending means the consent flow did not finish, so repeat it before going further.
Choose pull, push or both per calendar
Decide, per user calendar, whether ERPNext should pull events from Google, push ERPNext events to Google, or synchronize in both directions. Document the decision with the business owner, because a two-way sync can cause the same event to be edited on either side. Set the chosen direction on each user's Google Calendar record and save. Confirm the saved direction matches the decision for every user before you run a test.
Run a test event in each direction
Create a test event in Google Calendar for an authorized user and wait for the next sync cycle, or trigger a sync from the Google Calendar record if the screen offers one. Confirm the event appears in ERPNext's Event list. Then create an event in ERPNext that is set to push and confirm it appears in Google Calendar. Delete both test events afterwards. If an event is missing, check the authorization status and the scheduler, since the sync runs as a background job and does not happen instantly.
Confirm sync errors are visible to administrators
Review the Error Log and the Google Calendar record for any failed sync attempt from the test. Confirm that a deliberately revoked or expired authorization produces an error an administrator can see, so that a broken connection does not fail silently after go-live. Ask your ERPNext implementation partner or internal admin to record who receives these errors and how often they are checked. The step is complete when the team can describe where a failed sync shows up and who acts on it.
What the Calendar sync moves and where it can conflict
The Calendar integration works in two directions. Depending on the option you choose, ERPNext can pull events from Google Calendar into ERPNext, or push ERPNext events to Google Calendar, after OAuth 2.0 credentials are created in Google Settings and calendar access is authorized. Because the connection is made per user, each user authorizes their own Google account, and the events that move are those in that user's calendar. A shared team calendar, or an event owned by someone else, only syncs for the users who have connected their own accounts. Decide before rollout which direction each group needs, and whether a user should sync in both directions at all.
The main risk is collision. If the same event is edited in ERPNext and in Google Calendar between sync runs, the two copies disagree and the reader needs a rule for which one wins. Set an ownership rule per event type: for example, sales meetings tied to a customer record are edited in ERPNext, while personal appointments stay in Google. Write that rule down and train users on it, because the sync cannot judge intent. Test with a few accounts and deliberately edit the same event in both places to see what the version you run does.
Confirm three behaviors in the ERPNext Google Calendar documentation for your exact version before you go live: how deletions made on one side are handled on the other, how recurring events are expanded and kept in step, and how attendees, reminders and time zones are mapped. Do not assume these behave the same way in every release. Record the answers in your rollout notes, and include a deletion and a recurring-series test in your acceptance checks so the team knows what a user will actually see.
Using Google Drive as an offsite backup destination
The Google Drive integration sends ERPNext backups to a named folder on a schedule you choose, after OAuth 2.0 credentials are authorized. The cards below cover the decisions that sit around that upload: who owns the account, how the folder is shared, how long copies live, and whether a restore has ever been tested.
Authorization with OAuth 2.0 credentials
Drive access starts with OAuth 2.0 credentials created in Google Settings, followed by an authorization step that grants ERPNext permission to write to Drive. Decide before setup which Google account performs that authorization, because the grant is tied to that identity. Confirm the exact consent screen, scopes and redirect values against the release you run, since the setup steps are documented per version and may change.
Ownership of the Drive account
The account that holds the backups should belong to the organization, not to an individual employee. If the person who authorized the integration leaves or loses access, scheduled uploads can stop without an obvious error. Use a dedicated service-style mailbox with two-factor authentication, a documented owner, and a recovery path that IT controls.
Folder naming and sharing
Uploads land in a named Drive folder, so the folder name and its sharing settings define who can read backup files. Business data in a backup can include customers, suppliers, invoices, payroll-related records and stock values. Limit sharing to named administrators, avoid link-based sharing, and review membership on a fixed schedule rather than only when someone asks.
Backup frequency and failure visibility
The integration uploads at a frequency you choose, so the schedule sets your recovery point. Match it to how much transaction data your business can re-enter after a loss. Also confirm where failed uploads are reported, such as failure emails or the error log, and assign someone to read them. A silent failure can leave a backup folder that looks current but is weeks old.
Retention in Drive
The integration places backup files in Drive but does not, on its own, define how many generations you keep. Decide the retention period with your finance and compliance owners, then check whether old files are removed by ERPNext, by a Drive rule, or by a manual process. Confirm the behavior in your release, because the handling of older backups is a common gap in offsite plans.
Restore testing and version placement
A backup is only useful after a restore has been completed on a separate environment. Schedule restore tests that download a file from Drive, restore it to a non-production site, and check document counts, ledger balances and attachments. Because backup scheduling and where the integration sits can differ by version, confirm both against the release you run, including whether it is provided in the core app or a separate offsite backup app.
Which ERPNext and Google fields and identities map to each other
This table compares each ERPNext object with its Google counterpart, the direction data should flow and who should own the truth. Read it before you authorize OAuth 2.0 credentials, because the owner and direction you pick for each field decide what gets overwritten later. Items marked to be confirmed depend on the connector version in your environment.
| Field or identity | ERPNext side | Google side | Decision for the owner and direction |
|---|---|---|---|
| User identity | ERPNext User, matched by email address | Google account used to authorize Calendar access | Confirm each ERPNext user maps to one Google account and that shared or service accounts are excluded |
| Calendar events | ERPNext Event document | Google Calendar event on the authorized calendar | Choose pull from Google, push to Google, or a stated split; the chosen direction sets which side wins on edits |
| Event attendees | Event participants linked to ERPNext users or contacts | Event guests on the Google event | Confirm whether external guests should be stored in ERPNext or left only in Google |
| Google Contacts | Contact or Customer record (mapping to be confirmed) | Google Contacts entry | Mapping to be confirmed with the connector version; decide who owns names and phone numbers before any sync |
| Backup folder | Backup files generated by ERPNext on the chosen schedule | Named Google Drive folder | Confirm the folder name, the account that owns it and who can read backup files, since backups contain business data |
| Backup frequency | Scheduled backup setting in ERPNext | Upload time to the Drive folder | Confirm retention on the Drive side, because ERPNext does not control deletion of files already uploaded |
| Credentials and scopes | OAuth 2.0 client settings in Google Settings | Google Cloud project, consent screen and granted scopes | Use separate credentials per purpose where your policy requires it, and record who holds the client secret |
Securing OAuth credentials and Google access
The Google integrations run on OAuth 2.0 credentials that you create in Google Cloud and enter in ERPNext's Google Settings, so the security of this setup depends on the Google project, the consent you grant and who can change the settings. The cards below cover the controls to decide before go-live and the checks to repeat over time.
Scope consent to what each integration needs
Each integration asks Google for its own access: Calendar for event sync, Contacts for contact sync and Drive for backup uploads. Authorize only the integrations you enable, and confirm the scopes shown on Google's consent prompt match those purposes before you approve them. A Drive grant that is used only for backups should not be reused for other file access. Ask your partner to document which scopes each enabled feature requests, so a reviewer can compare the list with the configuration.
Limit who can edit Google Settings
Google Settings holds the client ID and client secret that identify your ERPNext site to Google. Anyone who can edit that document can point the integration at a different Google project or change where backups go. Restrict edit rights to a small administrator role, and review that role's membership on a schedule. Confirm the access model with the ERPNext permission settings in your own environment, since role names and defaults depend on your version and configuration.
Protect the client secret
The OAuth client secret is a credential, so treat it like a database password. Do not paste it into tickets, chat, screenshots or shared runbooks, and keep exports and backups that include the Google Settings record restricted to the same people who can manage it. When rotating the secret in Google Cloud, update the value in ERPNext immediately and re-authorize the integrations so the old secret is no longer in use. Ask who holds the secret in your organization and where a copy is stored.
Review the Google Cloud project and consent screen
Check which Google Cloud project owns the OAuth client, who has owner or editor rights on it, and how the consent screen is configured. A project shared with unrelated teams or left under a former employee's account is a common source of unexplained access. Confirm the consent screen shows your organization's name and a support contact, and that the redirect URI registered for the client matches your ERPNext site address exactly. Repeat this review after staff changes and before any major upgrade.
Revoke access when people leave
Google integrations can run under an individual user's account, so an employee who leaves may still hold authorized access to that user's calendar or contacts. Remove the user from ERPNext, revoke the app's access in the user's Google account or the Google Workspace admin console, and confirm that scheduled Drive backups still run under an account you control. Ask your partner which step removes the stored tokens in ERPNext, and test the procedure with one departing-user scenario before you rely on it.
Keep login policy separate from integration access
Google OAuth for Calendar, Contacts and Drive decides what ERPNext can read or write in Google. It does not decide who can sign in to ERPNext, how passwords are set or whether two-factor authentication is required. Those are login policies, and they are configured separately in ERPNext, including any Social Login Key for Google sign-in. Review both sets of settings in one pass so a user who loses login access is also removed from the integration, and so an integration grant does not quietly become a sign-in path.
Why the Google connection fails and how to fix it
This table lists the failures most often seen when ERPNext is connected to Google Calendar, Contacts and Drive, with the likely cause and the check to run for each. Work down the rows in order, since the redirect URI and consent problems block everything that follows. The main takeaway is that most failures trace back to OAuth configuration or the Google account used for authorization, not to ERPNext itself.
| Symptom | Likely cause | Check to run |
|---|---|---|
| Google redirect error after sign-in | The redirect URI in the Google Cloud OAuth client does not exactly match the site URL ERPNext uses | Compare the authorized redirect URI in Google Cloud with the callback URL shown in Google Settings, including protocol and trailing path |
| Authorization completes but no events appear | The user authorized a different Google account than the one whose calendar holds the events | Confirm the signed-in Google account in the browser and in the user's Google Calendar settings before reauthorizing |
| Sync stops after working for a period | Authorization was revoked in the Google account, or the refresh token expired because the OAuth app is still in testing mode | Check the account's third-party access list in Google and the publishing status of the OAuth consent screen |
| Calendar events missing or only partly synced | The OAuth grant does not include the Calendar scope, so the integration can read or write only part of the data | Review the scopes approved on the consent screen and reauthorize with the Calendar scope included |
| Contacts do not import or update | The Contacts scope was not requested or approved, or the user declined that permission on the consent screen | Reauthorize and confirm each permission on the consent screen, then run a test sync with one contact |
| Backups do not appear in the Drive folder | The folder name in Google Drive settings does not match an existing folder, or Drive access was never authorized | Verify the folder name and that the authorized account owns or can write to it, then trigger one manual backup |
| Backups stop after a period | Scheduled backup frequency is not running, the scheduler is disabled, or the token needs renewal | Check the scheduler status on the site and the last backup log entry, then reauthorize Drive access |
| Duplicate or overwritten events and contacts | Two-way sync with pull and push enabled on overlapping records, so edits in each system overwrite the other | Choose one direction per record type, reconcile duplicates once, and test edits in both systems before enabling sync for all users |
Questions buyers ask about the ERPNext Google integration
What drives the cost of a Google Calendar and Drive integration for ERPNext?
The cost depends mostly on how many people and Google accounts are involved, how many sync directions you need, and how much testing your rollout requires. Calendar sync can run in pull, push or both directions per user, and each direction needs its own decisions about which events move and who owns them. Drive backups add a question about folder structure, retention and who receives failure alerts. Costs are split between your internal staff time, Google Workspace administration and any partner effort. Ask for a written scope that lists each user group, each sync direction, each Drive folder and the test cases you expect the partner to run. A fixed-scope quote follows from that list. DeployOpen does not publish prices.
How long does configuring and testing the Google integration take?
Duration depends on how many Google projects, OAuth clients and user accounts you must set up, and on how much validation your change process requires. The core steps are creating OAuth 2.0 credentials, entering them in Google Settings, authorizing access for each user or backup account, and then confirming that events or backups land where you expect. Testing takes longer than setup when you need to check time zones, recurring events, deleted events and permission changes. Ask your partner for a timeline tied to the written scope and to your own change calendar. Confirm the exact steps for your ERPNext version against the ERPNext Google Calendar and Google Drive documentation before you commit to a date.
What does our team need to provide before the work starts?
Your team needs to provide administrative access to the Google Workspace or Google Cloud project that will hold the OAuth 2.0 credentials, a decision on which Google accounts own the synced data, and named ERPNext administrators who can enter the settings. You also need a list of users in scope, the Calendar behavior you want for each group, and the Drive folder name and backup frequency. Confirm whether your organization restricts third-party OAuth apps or requires an approval workflow in Google Workspace, because that approval can set the start date. Write these inputs into the scope document so the quote reflects what you have actually agreed to provide.
Can an in-house administrator set this up without outside help?
Yes, a competent in-house administrator with Google Workspace and ERPNext access can often complete a basic Calendar or Drive setup by following the vendor documentation. The harder part is not the first connection but the decisions around it: which account owns the credentials, how tokens are rotated when someone leaves, who reviews backup failures, and how the setup is tested before users rely on it. If your team lacks a Google Cloud or ERPNext administrator who can own those decisions, a partner can help with design and verification. Whichever route you choose, record the owner, the credentials location and the restore test in your runbook.
Does the integration cover Google Contacts too, and what changes if it does?
The Google Calendar and Google Drive integrations are the supplied documented scope for this topic. If you also want Google Contacts, treat it as a separate scope item, because contact data carries different questions. You need to decide the direction of sync, how duplicate contacts are matched against ERPNext customers and suppliers, which fields map, and who may see personal data that is now copied between systems. Confirm with your partner and with the ERPNext documentation whether a Contacts connector is available for your version before assuming it exists. Any custom mapping or matching logic adds design and test time and should appear as its own line in the written scope.
What happens to our data privacy and access when Google accounts are connected?
Connecting Google accounts gives ERPNext access to the data those accounts authorize, so the scope of each OAuth grant matters. Calendar events can contain customer names, deal details or personal information, and Drive backups contain your full ERPNext database. Limit access to the accounts and folders you need, restrict who can view the stored credentials, and decide where backups are retained and who may restore them. Review your data protection obligations with your compliance team, since DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations.
What can go wrong after go-live, and who maintains it?
The most common issues are expired or revoked OAuth authorizations, changes to Google Workspace admin policies, users who leave and take their authorization with them, and backups that silently fail. Calendar sync can also duplicate or delete events when both directions are enabled without clear ownership rules. Ongoing maintenance covers monitoring backup runs, rotating credentials according to your policy, reviewing authorized users and re-testing after ERPNext upgrades. Ask whether the scope includes operational handover and whether a support retainer is needed. DeployOpen offers ongoing support as a retainer, and that cost should be quoted separately from the initial fixed-scope work.
How DeployOpen scopes and delivers the Google integration
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, and the Google connection is handled the same way. We agree the scope in writing before work starts, then set up the OAuth 2.0 credentials, Calendar, Contacts and Drive settings on your ERPNext site and hand over a record of what was configured.
How we scope
- Engagements are fixed-scope, with the Google services, users and sync directions agreed in writing before work starts.
- We confirm which Google accounts, Workspace domains and ERPNext sites or users the integration will cover.
- We ask you to confirm who can create the OAuth 2.0 credentials in Google Cloud and who approves the consent screen.
How we build
- We create the OAuth 2.0 credentials and enter them in Google Settings on the agreed ERPNext site.
- We configure Calendar pull or push direction, Contacts handling and Drive backup folder and frequency to match the written scope.
- We test authorization, sync results and backup uploads on a non-production site before anything reaches live users.
How we hand over
- You receive documentation of the configured settings, the authorized accounts and the Drive folder used for backups.
- We document how to revoke access, rotate credentials and reauthorize a user when a Google account changes.
- Your team gets a walkthrough of the checks to run after go-live, such as confirming a test event and a test backup upload.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, which can cover Google-side changes that affect sync.
- We can review the integration again when you upgrade ERPNext, since the Google settings depend on the installed version.
- Ask any partner to confirm in writing which Google changes and ERPNext releases their support covers.
