Skip to main content
ConfigView gives you per-integration control. Connecting an integration from /admin/integrations/ installs everything needed to pull its data; disconnecting 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 open an integration (e.g., AWS) at https://{companyname}.configview.com/admin/integrations/AWS and click Connect, 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 fill in the actual values under Credentials on the same page.
  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 from the Default run time button on /admin/integrations/ — see 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, disconnect the integration and connect it again.
Fill in the credentials before you connect, or immediately after. The first one-shot run will fail with permission errors if they are empty — that’s normal. Once they are correct, click Run now on any collector on the integration’s page to retry, or wait for the next scheduled fire.

​
Checking that a credential actually works

Storing a value and storing the right value are different things, and several vendors make it easy to confuse the two — the Azure portal shows a client secret’s ID next to its Value, and pasting the ID gets you a credential that saves happily and fails every API call. So the Credentials section verifies as well as stores:
  • Saving a secret runs that integration’s health check straight away and tells you what happened. If the credential is wrong or under-scoped, you get the vendor’s own error — AADSTS7000215, 401 Unauthorized, insufficient privileges — while you still have the console open, instead of finding out from an empty table days later.
  • Each integration shows its own verdict: Verified, Failing, or Never verified, with how long ago it was checked. “Never verified” is deliberately not the same as healthy.
  • Verify now re-checks an integration whose secrets are all filled in, without saving anything.
  • Every enabled integration is re-checked nightly, so a credential that expires quietly — Looker API3 credentials are the usual case — turns amber on its own rather than waiting for someone to notice the data stopped.
If a check fails, open the integration: the failing checks are listed above the credential fields, with a link to that integration’s setup guide.
One credential often powers several integrations — a single Azure app registration backs both Azure and Microsoft 365, and one Meraki key covers every Meraki product line. Saving it verifies each of them, and if there are more than a handful the remainder are picked up by the nightly check.

​
Disabling an integration

When you click Disconnect and confirm, 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.
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 disconnect the whole integration — instead, open each collector’s Edit schedule and click Stop schedule. That pauses the schedule without dropping tables.
If any dropdb script fails, the integration is kept connected 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 reconnect an integration you previously disconnected, ConfigView restores any per-collector 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 reconnect AWS — you don’t have to set it again. Tables and data are not restored — reconnecting 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 (disconnect, rotate the IAM user, reconnect with new keys)

​
What’s preserved if scripts ship in a future update

The master scripts repository updates automatically every 5 minutes. When new collectors arrive in an integration you already have connected:
  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

​
Common questions

Can I disconnect an integration to save costs without losing data? No — disconnecting drops all tables. Stop the individual collectors instead (Edit schedule → Stop schedule); that pauses them without dropping anything. If I have hundreds of collectors and want to pause one for a week, do I have to click each one? Stop just that collector on its integration’s page. Bulk pause/resume per integration is on the roadmap. Does reconnecting 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 reconnect. What happens to my saved queries when I disconnect an integration? The saved queries themselves are preserved at /admin/app/. They will return empty results until you reconnect the integration and its tables refill.