# Pre-Install Checklist

*Audience: Salesforce administrator and Google Workspace administrator · Applies to: Auto Task via Google Meeting (`ribot`) v1.5*

## How to use this checklist

This is a short, deliberate checklist to complete before you begin the installation in the target Salesforce org. Every item here is something that, if missing, will stop or delay the install. Working through it in advance turns installation day into a smooth sequence rather than a series of interruptions.

Each item is marked with who is responsible. Some require the Google Workspace administrator, who may be a different person from the Salesforce administrator. If so, coordinate before you start — several Google items have to be done in order.

> **The single most common delay** — The OAuth consent screen and credentials in Google Cloud Console take the most time and depend on Google Workspace admin rights. If one person holds Salesforce admin and another holds Google admin, agree a time to work together. Do not start the Salesforce side expecting to finish in one sitting if the Google side is not ready.

## Section A — Salesforce org readiness

Responsibility: Salesforce administrator.

* [ ] You have System Administrator access to the target Salesforce org.
* [ ] You can confirm the org edition supports installing managed packages (Enterprise, Unlimited, or Developer; Professional may require feature confirmation).
* [ ] You have the install link or AppExchange listing for the Auto Task via Google Meeting managed package, version 1.5.
* [ ] My Domain is deployed and active. The OAuth callback depends on your org domain, so this must be settled first.
* [ ] You know which users will be administrators of this feature and which will be standard users — the two roles get different permission sets.
* [ ] You have a sandbox available, or have agreed with the customer that installation will be performed directly in production with a pilot group.

## Section B — Google Workspace readiness

Responsibility: Google Workspace administrator.

* [ ] You have administrative access to Google Cloud Console for the organization's Google Workspace.
* [ ] You can create a new Google Cloud project, or you have identified an existing project to use.
* [ ] You are able to enable APIs on that project — specifically the Google Calendar API, Google Drive API, Gmail API, and Google Docs API.
* [ ] You can configure the OAuth consent screen. Decide in advance whether it will be Internal (recommended when only your own Workspace users need it) or External.
* [ ] You can create an OAuth Client ID of type Web application and retrieve its Client ID and Client Secret.
* [ ] The Google Workspace users whose meetings will be processed have Gemini note-taking available and in use, so that notes actually exist for the package to read.

> **Why all four APIs** — Calendar lets the package see meetings; Drive and Docs let it locate and read the Gemini note documents; Gmail is used by the package as part of meeting and notes handling. All four must be enabled or processing will fail partway through.

## Section C — Information to have in hand

Responsibility: shared. Collect these values before configuration so you are not switching between systems mid-setup.

| Item                                  | Where it comes from                                           | Needed for                                      |
| ------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------- |
| Salesforce org domain (My Domain URL) | Salesforce Setup → My Domain                                  | Building the OAuth redirect URI                 |
| OAuth redirect URI                    | Constructed: your domain + `/apex/ribot__GoogleOAuthCallback` | Entered in Google Cloud, and must match exactly |
| Google Client ID                      | Google Cloud Console → Credentials                            | Salesforce custom metadata record               |
| Google Client Secret                  | Google Cloud Console → Credentials                            | Salesforce custom metadata record               |
| Assignment object & field             | Decided with the customer (see note below)                    | Salesforce custom metadata record               |
| List of pilot meetings                | Agreed with the customer's team                               | First use of the dashboard                      |

> **Decide the assignment object and field early** — Configuration includes an "assign object" and "assign field" value that tells the package how to resolve who a task is assigned to. For a standard rollout this points at the User object. Confirm it with the customer before install day so configuration is not held up by an open question.

## Section D — Decisions to confirm with the customer

These are not technical steps. They are choices that should be settled with the customer so the install reflects how they intend to work.

* Which meetings are appropriate to include — confirmed, including any meeting types that should be excluded for confidentiality.
* Who will own the review queue and approve extracted items — named individuals, not a vague team.
* How often processing should run — the scheduled job frequency (for example, daily or hourly).
* Acknowledged whether any project-management integration (e.g. Milestones PM+) is in scope. The package creates standard Salesforce Tasks only; connecting approved items into a PM tool is separate future work.

## Section E — Ready to proceed

When every box above is checked, you are ready to begin. Proceed to the [Administrator Guide](/getting-started/administrator-guide.md) and follow it in order.

> **Final check** — If any box in Sections A, B, or C is unchecked, stop and resolve it first. Beginning the install with a gap — especially a missing Google API or an undeployed My Domain — leads to a partially configured org that is harder to diagnose than a clean start.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.realintelligence.com/getting-started/pre-install-checklist.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
