Examples: GPTs Connected to a CRM, Calendar, and Database

Status as of November 5, 2026: GPTs are in their final weeks. OpenAI is retiring custom GPTs on December 11, 2026 (February 11, 2027, for certain Enterprise workspaces with an exemption). Personal, Free, Go, Plus, and Pro accounts can no longer create or publish new GPTs; in Business, Enterprise, and Edu workspaces, creation depends on settings, and it ceased on October 26, 2026, in affected Enterprise workspaces. Existing GPTs remain usable and editable if your plan allows until retirement; your conversations with them will remain accessible afterward. The migration (Migrate to plugin, in My GPTs) converts instructions into a skill, the knowledge base into reference files, and connected applications into apps; custom actions are not transferred. This lesson explains how GPTs work to help you maintain them, migrate them, and adapt their principles to a plugin (Lessons 15–17).

From theory to practice

You now know what an Action is and how to secure its authentication. It’s time to see what a connected GPT looks like outside the lab. This lesson breaks down three real-world examples—a CRM, a calendar, and a database—detailing the initial need, the chosen configuration, and what the user gets day to day. You’ll see that beyond tool differences, all three setups follow the same design principles, which we’ll outline at the end of the lesson.

Case 1: Querying your CRM in natural language (HubSpot)

Imagine a sales director who spends their days bouncing between meetings. Every time they want to check an opportunity’s status, they have to open HubSpot, navigate filters, and find the right view. Their need is simple: ask questions as they would a human assistant and get an answer without leaving the chat.

The configuration is intentionally minimal: the OpenAPI schema exposes only three endpoints—GET /contacts to search contacts by name, company, or status; GET /deals to list opportunities with filters (amount, stage, date); and POST /notes to add a note to a contact. Authentication relies on the access token of a private HubSpot app, passed as a Bearer token, with permissions limited to reading and adding notes. This choice isn’t arbitrary: even if a malicious user manipulated the GPT, it couldn’t modify a deal or alter contact details because the API itself forbids it. The GPT’s instructions lock down the scope a second time: they specify that it is a sales assistant connected to the HubSpot CRM, that it must use the API whenever asked about a contact or opportunity, that it must rephrase any note and ask for confirmation before adding it, and that it must never modify a deal’s status or contact details.

In practice, the result changes the sales director’s daily routine. They type “What are my deals in negotiation over €50,000?” and get a formatted list. They ask “Show me contacts from the company Durand & Fils” or dictate “Add a note to contact Marie Leroy: call on March 15, interested in the Premium offer”—the GPT rephrases, waits for the green light, then writes to HubSpot.

Case 2: Managing a calendar via chat (Google Calendar)

Second scenario: an executive assistant juggles their manager’s agenda, handling meeting creation, last-minute rescheduling, and availability checks. Here, unlike the CRM, writing is central to the need—you must be able to create, move, and cancel events. The OpenAPI schema therefore covers four endpoints: GET /events to list events for a period, POST /events to create an event, PUT /events/{id} to modify an existing event, and DELETE /events/{id} to cancel one.

Because the GPT touches personal Google data, authentication uses OAuth 2.0 with only the calendar.events scope: the GPT can read and write events but cannot touch calendar settings. The greater the write power, the more critical the instruction guardrails become. These require the GPT to summarize any creation or modification and ask for confirmation before acting, demand double confirmation before any deletion, and instruct it to systematically check for scheduling conflicts before proposing a slot.

In practice, the assistant asks “What do I have tomorrow afternoon?”, “Schedule a meeting with the marketing team Tuesday at 2 PM for 1 hour,” or “Move the check-in with Pierre from 10 AM to 11 AM.” The GPT checks availability, announces what it’s about to do, and executes only after validation. The friction added by confirmation is the modest price of an agenda that never gets wrecked by a misunderstanding.

Case 3: Exploring a feedback database (Airtable)

Third case: a product team centralizes tickets and customer feedback in Airtable, but not everyone masters filter syntax. Instead of training everyone on the tool, the team puts the database into conversation. Two endpoints suffice: GET /records to list records with filters and sorting, and POST /records to create a new record. Authentication uses an Airtable personal access token, passed as a Bearer token, with access restricted to only the “Product Feedback” base—other bases in the workspace remain invisible.

The instructions give the GPT its role as a product assistant connected to the feedback database, tell it to query the base with appropriate filters whenever a question concerns customer feedback, and enforce a response format: a table with columns for date, client, category, and summary. Most importantly, they set a clear limit: the GPT can create new tickets but never modify or delete existing ones. Any team member can then ask “How many bugs were reported this month?”, “What are the most recent feedback items on the billing feature?” or dictate “Create a ticket: display bug on the payment page, reported by client Dupont on March 28.”

What these three cases have in common

Stepping back, three patterns run through these different setups. The first is the golden rule of connected GPTs: free reading, controlled writing. All three GPTs consult their data without friction, but none writes without explicit user confirmation. The second pattern concerns instructions: a GPT doesn’t guess when to trigger an Action. In all three cases, the instructions explicitly state “when the user asks for X, use action Y”—without this directive, the model risks answering from memory instead of querying the source. The third pattern is scope sobriety: none of the three GPTs exposes its tool’s entire API. Just two to four endpoints, chosen for the use case, nothing more.

To adapt this approach for your own needs, follow the build order these three examples illustrate:

1. Identify a tool you use daily that has an API, and define two or three concrete use cases—the questions you ask most often
2. Create a minimal OpenAPI schema with only the necessary endpoints
3. Configure the appropriate authentication (API key or OAuth)
4. Add guardrails in the instructions for any write operations
5. Test with real queries before opening access to others

A word on pitfalls observed with beginner creators. The most frequent is connecting an API “just in case,” without a specific use case: you end up with a GPT that can theoretically do everything but nothing well in practice. The most dangerous is allowing writing without confirmation—a GPT that creates or modifies data without validation can cause real damage in a CRM or shared calendar. Also consider API errors: if the service is unavailable or returns an error, your GPT must know what to tell the user rather than inventing an answer. Finally, resist the temptation to expose too many endpoints: each consumes context, and beyond five, the GPT’s precision degrades.

Your turn

Action or app? For one of the three cases, or for a tool in your company, first search the ChatGPT Plugins directory to see if an app already exists for that service. If yes, note what it allows and what’s missing; if not, draft the action plan: schema operations, authentication mode, minimal rights, and guardrails in the instructions. Keep this plan: it’s the foundation for a plugin integration, since actions are not migrated.

Official sources: Configuring actions in GPTs (OpenAI Help Center: authentication, OpenAPI schema, testing, limits) · Plugins in ChatGPT (directory and apps) · Authentication (Airtable: access tokens) · Private apps (HubSpot: access token)

Key takeaways

• GPTs connected to real tools (CRM, calendar, database) solve concrete everyday problems
• Apply the golden rule “free reading, controlled writing”: always confirm before modifying
• Explicitly mention Actions in the instructions so the GPT knows when to trigger them
• Limit endpoints to the strict minimum (2 to 5) and plan for API error handling
• Start simple—one tool, two endpoints—and enrich progressively