Slide: boxes, protected systems, backup history and the restores you ran

Slide is a backup and disaster-recovery product built around a box on the customer site and the systems protected behind it. This connector reads that estate into Current so each partner's backup posture sits on their company record before anyone asks for it: which boxes are checking in and how full they are, which systems backed up and when, whether the last backup actually boots, and which restores were run. Current reads Slide and can never change anything in it.

1. 1
   1 · Sign in to the Slide Console as an administrator

   One Slide account covers every customer you back up, and each customer is a client inside it. So this is one token for the whole estate rather than one per customer, and there is no region to choose: Slide runs a single service.
2. 2
   2 · Mint the token as a read-only user

   A Slide API token carries the role of the user who creates it; there is no separate role picker on the token. So add a user with the Read Only role for Current under Users (or use one you already have), sign in as that user, open My Settings ▸ API and create the token there. That caps the token at Slide's end as well as at Current's, and Current only ever reads.
3. 3
   3 · Copy the token

   Copy it as it appears and keep it somewhere safe. Give it a name a colleague will recognise in a year, something like "Current reporting", so the person looking at this screen later knows what it feeds.
4. 4
   4 · Paste it into Current and press Test connection

   There is one field. Current reads your account once to prove the token and your client list once to see what it can reach, then stores the token on its servers only.

1. 1
   Open the Slide card

   In Current's left sidebar open Integrations (it sits under Workspace, so Tenant Admins have the link) and find Slide under Backup & continuity.
2. 2
   Paste the token and press Test connection

   Current sends it as an Authorization header, never in a web address, and it is never written into a status, a message, or a log. The browser does not see it again after you press the button.
3. 3
   Check what the test reports

   The success message names your Slide account and how many clients the token can see. A token that authenticates and reports no clients usually means the clients have not been created in Slide yet, in which case every box and system arrives unfiled until they are.

Slide syncs every 6 hours on a schedule, plus whenever you press Sync now on the card. Each run reads your client list first, so the mapping panel fills on the very first sync, then boxes, then protected systems, then alerts, then the backup attempts since it last ran, then boot verification a system at a time, and finally the live restores. Two of those fill in gradually on a large estate. Boot verification is one request per protected system, so it works through them newest-seen first and covers the rest over the next few runs. And the first sync reads back one week of backup attempts rather than thirty days, so the thirty-day history fills over the following three weeks. Neither is an error, and the numbers say what they are measured over.

Every request Current makes to Slide is checked against a fixed list of read addresses before it is sent, and the list is matched exactly rather than by prefix. That last detail matters more here than with most feeds, because Slide's write operations sit at addresses that begin the same way its reads do: the address that lists protected systems is one character away from the one that edits a system, and the address that lists virtual machines is the same one that creates a virtual machine when it is asked differently. Matching exactly is what makes those unreachable rather than merely unused, including by a bug in Current. Two of Slide's own reads are also excluded on purpose: the file search inside a protected system, and the browse view of a live restore. Both would let Current look at a customer's own files, which a CRM should never do.

In Slide each end-customer is a client. Current lists all of them and links each to a company by normalized name, lowercased with punctuation and Inc/LLC/Ltd-style suffixes stripped, and only when exactly one company matches. Two companies that both fit stay unmapped for you to decide rather than being paired on a guess. Slide carries no link back to your PSA, so name matching plus this panel is the whole story.

1. 1
   Let the auto-matcher run first

   Every sync links each Slide client to the one company whose normalized name matches. Most map themselves; only the ambiguous ones need a hand.
2. 2
   Open the mapping panel

   Integrations → Slide → Manage → Customer mapping. It opens on the Unmapped tab, which lists every client the matcher could not place.
3. 3
   Map a client to its company

   On an unmapped row press Map, type a few letters of the company, and pick it. That client's boxes and protected systems attach to the company right away, rather than waiting for the next 6-hour sync.
4. 4
   Ignore internal or test clients

   For a client that should never map to a partner — your own systems, a lab, a demo — press Ignore. It moves to the Ignored tab and stops counting against the card's unmapped badge.
5. 5
   Fix a wrong match later

   The Mapped tab lists every linked client; Unmap corrects a bad auto-match, and the Ignored tab's Un-ignore brings a dismissed one back. A mapping you set by hand is never overwritten by a later auto-match, and neither is a manual unlink.

One definition drives the company card, the backups-failing alert and the dashboard tile, so they can never disagree with each other. A protected system counts as failing when its last good backup is more than three days old, or its most recent attempt failed, or its last boot verification came back with a warning or an error, or Slide itself has an open alert saying the system's backup failed or that it is not backing up.

• ＋A system whose backups are paused is not counted as failing. Pausing is a decision somebody made, and Current treats it the same way it treats a paused backup from any other product. The count of paused systems is shown separately so it is visible without being called a fault.
• ＋A sealed system is not counted as failing either, and it is worth knowing what sealed means: the encryption key is unloaded, so no backup can run until somebody loads it again. That is a real problem, but it is a different problem from a backup that tried and failed, so it gets its own count on the card.
• ＋A boot check that was skipped, is still pending, or was never run is unchecked rather than failed. Unchecked systems sit outside both halves of the verified figure and the card prints how many answered, so a low number never means the estate failed.
• ＋A backup that was canceled counts as neither a success nor a failure. A run somebody stopped, or one the box gave up on when the machine went away, has no outcome to record.
• ＋A backup status Current does not recognise counts as unknown rather than as a pass or a failure. If Slide adds one, Current says so instead of guessing.

• ＋The company record's backup section: protected systems and how many are failing, boot verification, the boxes with their storage and check-in state, and the restores that were run.
• ＋The backups-failing alert on a company, which counts Slide alongside any other backup product you have connected so a company raises one alert whichever tool saw the problem, and clears itself when the count returns to zero.
• ＋The backup chapter of a Strategic Business Review, including a line naming the restores performed in the period and how many of them were a real recovery rather than a test.
• ＋Dashboard backup metrics: protected systems, systems failing, and the share of backup attempts that completed over the last thirty days.
• ＋The company AI brief, which names the Slide numbers directly rather than blending them.

Some backup-monitoring products watch Slide directly. If you have one of those connected to Current as well, both connectors are describing the same machines from two different angles, so their counts are not meant to be added together: one counts protected systems and the other counts backup jobs, and one system can carry several jobs. Current keeps them on separate cards with their source named on each rather than merging them, because there is no shared machine identifier between the two that would make a merge reliable rather than a guess.

Disconnect on the card stops the sync and forgets the token. Everything already synced stays where it is and simply stops updating, and reconnecting with a new token picks up from there, your client mappings included. Partner (read-only) viewers never see any of this data; it is blocked at the database, not just hidden.