> ## Documentation Index
> Fetch the complete documentation index at: https://support.configview.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Enabling and disabling integrations

ConfigView gives you per-integration control. Checking an integration at `/admin/cron/` installs everything needed to pull its data; unchecking removes it cleanly. This page explains exactly what happens at each step so you know what to expect — and what's preserved if you re-enable later.

## Enabling an integration

When you check the box for an integration (e.g., AWS) at `https://{companyname}.configview.com/admin/cron/` and click **Save**, ConfigView does the following, in order:

1. **Creates empty secret entries** in your Google Secret Manager for every secret the integration needs (e.g., `AWS_ACCESS_KEY`, `AWS_SECRET_ACCESS_KEY`, `AWS_DEFAULT_REGION` for AWS). You'll fill in the actual values at `/admin/secret/`.
2. **Copies the integration's scripts** from ConfigView's master repository into your runtime directory.
3. **Creates the database tables** by running every `createdb_*.py` script for the integration.
4. **Schedules every recurring script** at your configured default time (set the default once at the top of `/admin/cron/` — see [Schedules](/schedules)).
5. **Triggers an immediate one-shot first run** so data starts populating within minutes instead of waiting until the default time.

If any `createdb` script fails (most commonly because of a missing IAM action or a typo in a secret), the integration is **not** added to your selection. ConfigView keeps the partial state (scripts on disk, secrets created) so you can investigate the failure in the activity log at `/admin/activity/`. After fixing the root cause, toggle the integration off and back on.

<Note>
  After you enable an integration, fill in the secret values immediately at `/admin/secret/`. The first one-shot run will fail with permission errors if the secrets are empty — that's normal. Once secrets are correct, click **Run Now** on any script in `/admin/cron/` to retry, or wait for the next scheduled fire.
</Note>

## Disabling an integration

When you uncheck the box and click **Save**, ConfigView removes the integration in this order:

1. **Pauses every script** for the integration (`scheduler.remove_job` + database flag flipped to inactive).
2. **Drops the integration's tables** by running every `dropdb_*.py` script.
3. **Removes the scripts from your runtime directory** (the master repository copy is unaffected).
4. **Deletes the secret entries** from Google Secret Manager.

<Warning>
  Disabling an integration **drops all of its tables and data**. Historical rows are not preserved. If you want to keep the historical data but pause new collection, do not disable the whole integration — instead, use the **Stop** button on each individual script. That pauses the schedule without dropping tables.
</Warning>

If any `dropdb` script fails, the integration is **kept selected** to give you a chance to inspect what went wrong. Scripts that did succeed are reflected — meaning some tables may already be gone — but the schedule is paused and secrets are preserved until the operation completes cleanly. Fix the underlying issue (usually a permissions change or a manual table rename) and try disabling again.

## What's preserved if you re-enable

When you re-enable an integration you previously disabled, ConfigView **restores any per-script schedule overrides you had made**. For example, if you had set the AWS Lambda inventory script to run at 2:00 PM (instead of the default time), that 2:00 PM schedule comes back when you re-enable AWS — you don't have to set it again.

Tables and data are not restored — re-enabling re-creates the tables empty and triggers fresh first runs. Use this for:

* Temporary pauses during infrastructure migrations
* Onboarding test cycles in non-production environments
* Switching credentials (disable, rotate the IAM user, re-enable with new keys)

## What's preserved if scripts ship in a future update

The master scripts repository updates automatically every 5 minutes. When new scripts arrive in a folder you already have enabled:

1. The new scripts are copied into your runtime directory.
2. Any `createdb` scripts for the new tables run automatically.
3. **Any new `get` scripts are scheduled at your default time** with no action required from you.

This is how ConfigView ships new features (e.g., a new AWS service inventory) without making you re-do setup.

## At-a-glance summary

| What                 | On enable       | On disable          | On re-enable              |
| -------------------- | --------------- | ------------------- | ------------------------- |
| Secret entries       | created (empty) | deleted             | created again             |
| Database tables      | created         | dropped (data lost) | re-created empty          |
| Schedules            | set to default  | paused (preserved)  | restored at previous time |
| Scripts on disk      | installed       | removed             | re-installed              |
| Activity log entries | one per step    | one per step        | preserved across cycles   |

## Common questions

**Can I disable an integration to save costs without losing data?**
No — disabling drops all tables. Use the per-script **Stop** button to pause individual scripts without dropping anything.

**If I have hundreds of scripts and want to disable one for a week, do I have to click each one?**
Use the per-script **Stop** button. Bulk pause/resume per folder is on the roadmap.

**Does re-enabling re-fetch all historical data?**
No. Each integration pulls a service-defined window (e.g., AWS Cost Explorer pulls the last 30 days). Whatever the integration pulls naturally, you get on re-enable.

**What happens to my saved queries when I disable an integration?**
The saved queries themselves are preserved at `/admin/app/`. They will return empty results until you re-enable the integration and tables refill.