Connectors and keeping configurations current

What you’ll be able to do

Choose between uploading a file and connecting a live source
Connect sources with the least access the task needs
Keep a Project’s knowledge and instructions accurate over time, and tell people when they change

What you need to know

Uploaded files vs connectors

There are two ways to give Claude your material, and they behave differently over time.

Uploaded files (in a chat or in Project knowledge) are a copy taken at a point in time. That's good for stable, approved documents such as a signed policy, a published style guide or a finished report. If the original changes later, the uploaded copy does not update.
Connectors let you authorize Claude to read from services such as Google Drive, Gmail or Google Calendar, so it can work with your current material in those sources. That suits content that changes often or lives in many places: a weekly status doc, this month's email threads with a vendor, the calendar for next week.

Rule of thumb: a stable, authoritative reference works fine as an upload, while fast-changing material is better reached through a connector so you aren't working from a stale copy. Which connectors are available, and whether you can turn them on yourself, depends on your plan and your organization's admin settings.

Least access when connecting

Connecting a source gives Claude the ability to read what that account can reach. Treat it like giving a colleague access to your files: give what the job needs, no more.

Connect the sources the task actually requires. A newsletter Project probably needs the shared newsletter folder, not your inbox.
Follow your organization's policy on which services may be connected and what data may be accessed. Personal accounts connected to work tasks, and work data reached through personal tools, are both common policy problems.
Be especially careful with sources that hold regulated or confidential data, such as HR records, customer details or legal correspondence (Domain 6).
Review and disconnect connectors you no longer use. Access granted for a finished project shouldn't stay in place indefinitely.

A connector also doesn't make retrieved content trustworthy by default. Claude may pull the wrong version of a document or an outdated email, so check that the answer rests on the right source.

Keeping knowledge and instructions current

A Project that worked well in January can quietly give wrong answers in June because a policy changed, a product was renamed or a process was retired. Configuration is something you maintain, not something you set once.

Assign an owner. Every shared Project needs a named person responsible for its instructions and knowledge. "Everyone" usually ends up meaning no one.
Replace, don't stack. When a document is updated, upload the new version and remove the old one, or the two will conflict.
Make versions visible. Use clear names or a short note on what's current and when it was last updated, so people can tell what Claude is working from.
Review on a schedule and on triggers. Check the Project periodically, and also whenever a source document, policy, team or process changes.
Retest after changes. Rerun a few standard requests after you edit instructions or swap files, to confirm nothing else broke.

Inform the people who rely on it

The exam objective says to inform, as well as maintain and update. When you change a shared Project's instructions or knowledge, tell the people who use it what changed, why, and whether earlier outputs might need a second look. For example: "The Project now uses the 2026 travel policy; drafts from before Monday used the old mileage rate." Keep a simple change log with the date, the change and the owner. It makes later questions much easier to answer.

If keeping a configuration current would mean custom syncing, automated pipelines or connecting internal systems that have no available connector, that's work to escalate to Claude Developers or Architects. It isn't something to improvise with workarounds.

Key concept

Connect only what the task needs, use live sources for fast-changing content, and give every shared Project an owner who replaces outdated files, retests, and tells users what changed.

Exam scenarios often describe a Project that "used to work" or an assistant quoting outdated figures. The right answer usually targets the stale source (replace it or connect the live one) and the missing ownership, not a rewritten prompt or a different model.

Practice scenario

ScenarioA sales enablement lead built a team Project six months ago with the product price sheet uploaded as a file. Prices have changed twice since then; the updated sheets were added to Project knowledge but the original was never removed. Reps report quotes that mix old and new prices. To "fix it for good," a colleague proposes connecting the whole company Google Drive and the team's shared inbox.

Work it through, then open this

The root cause is stale, conflicting knowledge with no clear owner. The immediate fix is to remove the outdated price sheets and keep only the current one, or, if the price sheet lives in Drive and changes often, use the Drive connector for just that file or folder, where your plan and settings allow, so the Project works from the live source instead of a stale copy. Connecting the entire Drive and the inbox breaks least access and adds more chances to pull the wrong document. The lead should also name an owner, tell reps which quotes may have used old prices, and retest a few pricing questions after the change.

Hands-on exercise — Audit one Project’s configuration

Beginner · 15 min

What you’ll learn

Spotting stale or conflicting knowledge
Reviewing connector access against the task
Writing a short change note for users

Open a Project you use and list every knowledge file, noting for each one whether it’s current, whether there’s a newer version, and who owns it.
- Why: Stale and duplicate files are the most common cause of a Project going wrong quietly.
- You should see: At least one file that’s outdated, duplicated or has no clear owner. Remove or replace it.
If you use connectors, list which sources are connected and ask yourself whether each one is needed for the tasks in this Project.
- Why: Least access reduces both privacy risk and the chance of pulling the wrong source.
- You should see: A shorter list of necessary connections, and any unneeded ones disconnected according to your organization’s policy.
Make one improvement to the instructions or files, rerun two standard requests, then write a two-line change note for the people who use the Project.
- Why: Retesting catches side effects, and the note keeps users from relying on outdated assumptions.
- You should see: Consistent answers on the standard requests, and a note that says what changed, when, and what to recheck.

Exam traps

Connecting every account and folder available just in case

Connect only what the task needs. Broad access increases privacy risk and the chance of retrieving the wrong material.

Uploading a one-time copy of a document that changes every week

An uploaded file is a snapshot that won’t update. Fast-changing content is better reached through a connector, or refreshed on a set schedule.

Replacing a knowledge file without removing the outdated version

Old and new versions side by side produce conflicting answers. Replace the old file, don’t just add the new one.

Changing shared Project instructions without telling the people who use them

Users need to know what changed and whether earlier outputs need rechecking. Inform them and keep a simple change log.

Assuming a configuration stays correct forever once it works

Policies, products and processes change. Assign an owner and review on a schedule and whenever a source changes.

Treating a connector as a reason to skip checking what Claude retrieved

Live access can still surface the wrong version or an outdated email. Confirm the answer rests on the right source.

Sources

Claude Help Center
Claude Docs
Anthropic, Claude Certified Associate – Foundations Exam Guide v1.0 (July 2026)