Signed-in apps and test accounts
Let Skavelo learn the screens your signed-in users see, safely.
Most of a SaaS product sits behind a login. To learn those screens and draft walkthroughs for them, Skavelo needs to sign in with a test account.
Adding a test account
When you add or edit your web app on the Learning tab, turn on This app needs a login and fill in:
- Sign-in page: the address of your login page, for example
app.yourproduct.com/login. - Email or username and Password for the test account.
Skavelo signs in at the start of each run, then goes through your app page by page. On each page it opens the buttons, menus and tabs that show more, like Create dialogs and the actions menu on a row, and notes what's inside. That's how it learns where a control like Pause lives and drafts walkthroughs that go all the way through a task.
Use a dedicated test account
Create an account just for Skavelo, ideally on a staging environment or in a sandbox workspace, with sample data rather than real customer data. Give it the permissions a typical user has, so it learns the screens your users actually see.
Learning on staging, running on production
Skavelo can learn your app on staging and help users on production. Walkthroughs match pages by their path, such as /invoices/new, not by domain, so a walkthrough learned on staging.yourproduct.com runs on app.yourproduct.com. When an answer links to a page it learned from your app, the link goes to the same page on the site the user is on, so users never see your staging address.
Two things to check:
- Add your production address to Allowed sites on the agent's Install tab. The widget only runs on sites listed there.
- Keep staging close to production. If staging runs ahead with features users don't have yet, Skavelo may explain them; if production has screens staging lacks, Skavelo won't know about them.
Add some sample data
Skavelo can only learn what the test account can see. An empty account shows "No projects yet" where the list would be, so there's no row to open, no actions menu and no detail page behind it.
Before the first run, add one or two of each main thing in your product: a project, a customer, an invoice, whatever your users work with. Skavelo opens a few of each kind of page; it doesn't need many. After each run, the Learning tab lists screens that looked empty and anything else Skavelo couldn't reach, under What Skavelo couldn't reach.
How Skavelo keeps your app safe
- It never changes your data. While it opens buttons and menus, Skavelo blocks every request that could save something before it leaves the browser, along with anything the page tries to send over a live connection. Only signing in goes through.
- It doesn't click actions. It opens things that show more, like menus, dialogs and tabs. It skips buttons whose label sounds like an action (save, send, delete, pause, invite, pay and similar), never submits a form, and never clicks anything inside a dialog or menu it opened.
- It avoids risky links. It never follows links that look like log out, delete, remove, unsubscribe, cancel subscription or deactivate.
- Your password is protected. It's encrypted when you save it, used only to sign in during learning, and never shown again in the dashboard. To change it, enter a new one; leave the field empty to keep the current password.
Sign-in methods Skavelo supports
Skavelo signs in with a standard email or username and password form. Sign-in that requires a one-time code, single sign-on or a CAPTCHA isn't supported yet. If your app uses one of these, you can still teach Skavelo from your help docs, files and notes, and write walkthroughs yourself.
If Skavelo reaches a sign-in page
If a run lands on a sign-in page and no test account is set, the website card shows a notice. Add a test account and run learning again.