Know who can open your dashboard, and what they can change.

Who can open my dashboard?

Only an address that passes two checks. Your sign-in confirms who the person is before a byte of the page is served. Our seat list then confirms that this address holds a seat on your account. Pass the first without the second and you get a refusal page, not your numbers.

Identity is verified on every request, not remembered. Each request carries a signed session that is pinned to your dashboard, so a sign-in minted for one dashboard is refused at another. Your dashboard tells search engines not to index it, and its preview hostnames do not serve it, so the gated host is the one door.

Sign in with a link, not a password. Enter your address at login.trulata.com. A single-use link arrives at the address on your seat, works once and expires in 15 minutes. Hold seats on more than one account and the link lands on a chooser. There is no password to set, share or reset, and none for us to store.

Every part of the page is checked, not only the front door. One load of your dashboard makes eleven requests, and the file that carries your numbers is one of them. Each is checked against the seat list, so a removed address is refused at the data file too, not only at the front door.

What can someone with a seat change?

Every change the screen can make is logged, and this is the list today: seats (invite and remove), plan and billing, which Google accounts it reads and the keys for the tools you connect, your settings including any autopilot you switch on, a lead outcome on your own lead record, approving or publishing an article, approving an ad or asking for changes where your plan includes creative, and a request to our team. Ask TruLata can take the same actions, and pause, enable or change the budget of a Google Ads campaign, each after your yes. Everything else on the screen reads.

A lead outcome is a control on the Leads view. Press Not a lead beside a row, choose why (existing customer, spam or sales pitch, wrong number, out of area, other), add an optional note, and press Save. It writes to that lead's record and stands until your own team clears it with Undo. Where follow-up tracking is on, the same control records contacted, quoted, won or lost, and a lead with no record after two days wears a badge that says no contact marked yet.

A request opens a box that says Goes straight to your TruLata team. Send it and the toast reads Sent to your TruLata team, Ticket #N. Quote that number back to us any time. The Support view lists every ticket with when it opened, where it came from, its subject and its status, and our replies appear under it. Email [email protected] instead and it lands in the same list with its own number.

Requests go to your team as logged tickets; the engine's own writes to your ad accounts and your site go through their APIs and land in each account's change history. Budget and bid changes in your ad account are made within the limits set for your engagement, and the 7:05am watch reads that history every morning.

Team and Branding change the workspace itself, not your accounts. Team holds who has a seat. Branding holds a logo, PNG, SVG or JPG up to 2 MB, and a brand colour; the logo appears top right on every page. Neither touches anything outside the dashboard.

Check it in the demo. Open demo.trulata.com and go to Support. Press New request and the box opens. Website has the same form inline under Request a website change. The demo simulates the send; your instance hands you a ticket number. Open Team for seats used against plan seats and the roles Member and Admin.

What is written down, and who can read it?

Every change made through a dashboard is written down. The record holds the address that made it, what was asked for, the answer it got and the time. Set a lead outcome, send a request, change a seat, and each one lands in the same log. Refusals land there too, so an attempt that was turned away is as visible as one that worked.

Sign-ins are logged the same way, step by step. Asking for a link, using it, and any attempt to use it twice are separate lines, with the address and the dashboard. So the question of who opened your dashboard last month has an answer, and it comes with dates.

Reading the log is ours, and your view of it is your own dashboard. The log covers every account on one service, so it stays with our team rather than sitting behind a client screen. Ask and we will tell you what it holds for your account.

Rate limits sit in front of the same doors. Each account has its own ceiling per minute, counted for the signed-in person where there is one and by address where there is not, with a tighter ceiling on the few actions that cost real money to run. If a limiter cannot answer, the call is let through and the event is logged, so a counter outage keeps you working.

Your data moves under bank-level encryption (TLS), and browsers are told to keep it that way for two years, so a link to your dashboard cannot be downgraded to an open connection. Your numbers sit in a managed database with point-in-time recovery, so a bad hour can be rolled back rather than restored from last night.

What happens when a check cannot be made?

You stay in. If our seat service takes longer than two seconds to answer, a person who has already signed in is allowed through, and the decision is written to the log. The sign-in has confirmed who they are; our layer only narrows that set. A blip on our side must not lock you out of your own numbers, and a removed seat working a few minutes longer during an outage is the smaller failure.

Two refusals never relax. A login minted for a different dashboard is refused, because a wrong audience is not an outage, it is a token that was never for this door. A login with no email identity is refused, because a dashboard is a human surface and a machine identity holds no seat. Every fail-open is logged, so the gap is visible rather than silent.

Every release is rehearsed before it reaches you. The new version goes to a staging instance of the product first, and a real browser opens every tab of every account on it. Production is touched only when that walk is clean; a single failure leaves the running version in place. Before every deploy, a preflight checks the door itself. The redirect from preview hostnames points at your canonical host, and it is a 302, so a browser checks again next time instead of caching a 301 forever. The engine matches the canonical build. The data file is present and assets are pinned. No other client's name appears anywhere in your instance. No build junk ships. A failed check stops the deploy and the previous page stays up.

If the numbers behind the page are late, the page says so. The header stamp shows how old the data is. Refresh starts a real pull, two seconds to a little over three minutes depending on your sources, and the page reloads when the stamp moves. Every path through it ends in a reloaded page.