Encrypted intake, keys, and how the dashboard works
These answers cover the public Jobs site, the applicant apply flow, the Employer Dashboard, and the Staff Portal. Trades Backer is designed around linking: share one canonical apply link anywhere (including your own website) and keep intake consistent. If you have a question that is not covered here, use the Contact page.
Does Trades Backer read applications?
No. Applicant submissions are encrypted in the browser before upload. The server stores ciphertext plus a small, non-identifying manifest record used for dashboard sorting and workflow.
- Applications decrypt locally in the Employer Dashboard (in the employer's browser).
- Listing requests and Contact messages decrypt locally in the Staff Portal (staff key only).
What is a “KID”?
A KID is a short identifier (24 hex chars) derived from a private key. It scopes encrypted uploads and dashboard access. Employers and staff each have their own KID.
- Applicants encrypt to the public key associated with the listing's KID.
- The dashboard uses the private key to authenticate and decrypt for that same KID.
What does the server store?
For each submission, the server stores:
- sealed.json: small encrypted key material + AAD (size-capped)
- payload.bin: encrypted payload blob (size-capped)
- manifest row: minimal, non-identifying summary fields (example: position/trade, experience indicator, timestamps, and a non-PII source tag)
The manifest is used for dashboard filtering, workflow, and repeat-submission detection without storing plaintext contact fields.
Do I need a special account to use the dashboard?
The Employer Dashboard is key-based. Upload your employer private key (.pem) to authenticate.
The key stays in your browser; decryption happens locally.
If your organization uses a shared workstation, consider using a dedicated browser profile and do not enable “Remember Key”.
How long are submissions kept?
By default, ciphertext blobs are retained for a limited window (configured by the site operator; typical default is 180 days). After the retention window, blobs may be purged server-side while keeping a “purged” manifest row for basic history.
Employers should export what they need for their internal retention and compliance requirements.
Is the dashboard tablet-friendly? Is it a PWA?
Yes. The Employer Dashboard is a Progressive Web App (PWA) designed for trusted field personnel—touch-friendly on iPad/Android tablets, and installable to the home screen for an app-like experience.
The interface caches for fast loads, but fetching new submissions still requires network access.
Should we embed the application on our website?
We recommend linking to the canonical apply page (button, banner, or careers page). Linking keeps the encryption + file upload flow reliable across browsers and devices, and it keeps every channel pointed at the same standardized intake.
- Use a tagged link (?src= or UTM) to track where applicants came from.
- Unlisted (recurring) is an apply-link-only setup (no public project/job index pages).
Do you send email/text notifications for every application?
No. Trades Backer avoids noisy alerts. Applicants see an on-page confirmation after submitting. Employers and staff review in their dashboards when it fits their workflow.
We only send service communications when they’re necessary (listing verification, support follow-up, or critical system notices).
Will public jobs show in Google Jobs?
Public single-job pages are formatted so they can be crawled and understood as individual openings. Final inclusion still depends on Google's crawl, indexing, and content policies, so publication does not guarantee placement.
The safest distribution pattern is one canonical job detail page per public role, current job details, and removal or expiration updates when a role closes.
Should we share the job page or just our homepage?
Share the exact job detail page for each role. Do not make applicants hunt from a generic homepage if you already know the role they clicked.
- Better applicant experience.
- Cleaner source tracking.
- Stronger canonical signals for search discovery.
Why was Trades Backer built this way?
Trades Backer was shaped by real hiring friction seen by people working in and around the trades: rebuilding forms for each posting site, maintaining custom intake on employer websites, dealing with break risks after updates, worrying about personal-information exposure, and not having a clean read on which channels were bringing in the best applicants.
The platform is meant to reduce moving parts, keep one standardized apply path, and make the review workflow feel useful instead of overwhelming.
Why is Trades Backer intentionally lightweight?
It’s built from the ground up for skilled construction workflows, not as a generic “global” ATS. Fewer moving parts means fewer confusing settings, fewer dependencies to patch, and a faster review experience for busy teams.
Can I withdraw or delete my application?
Trades Backer can purge stored ciphertext for a specific submission when requested by the listing owner (employer/organization). If you need help, contact the listing owner or contact Trades Backer staff with the listing name and approximate submission time.
What should I avoid submitting?
Do not include high-risk identifiers (for example, SSNs). Those belong in later employer-controlled onboarding steps. Attachments should be relevant to the role (certifications, résumé, etc.).
Employers: how do listings go live?
- Submit a listing request via Request a listing (encrypted to staff).
- Staff confirms posting details and sets up a project bucket + keypair.
- Your listing appears under Jobs; share the canonical link everywhere.
- Review and export candidates from the Employer Dashboard.