Skip to main content

Installation

What TrueSign does by itself at installation, and what is left for you — with the reason behind every manual step.

1. What is automatic​

Nothing to ask for, nothing to click:

  • the 5 maintenance jobs are scheduled (status synchronization, approval reminders, weSign lifecycle, log purge, job purge) — see Jobs & synchronization;
  • the outbound call permissions for the signature provider's domains ship with the package;
  • the 10 permission sets are installed (but not assigned — §3);
  • labels, translations and static resources.

The administrator who installs receives TES_Admin, so as not to face an empty application.

2. The manual steps​

Step 1 — Create a public Site​

Mandatory. Two things need it: receiving the provider's notifications, and the weSign signing pages (an external signer has no Salesforce licence).

  1. Setup → Sites → New site.
  2. Note the site URL: that is the one the webhook will use.
  3. Assign the TES_Guest permission set to the site's guest user.
Why this step cannot be automated

A Salesforce Site is not packageable: its URL and its guest user belong to your org. TES_Guest, on the other hand, replaces the manual permission wiring: it ships ready, at least privilege — only the necessary classes and pages, no delete, append-only journals.

Step 2 — Connect the signature provider​

  • weSign (signing inside your org): nothing to connect. An org can run 100% weSign, with no third-party account at all.
  • Yousign: enter your API key in Setup → eSignature → Settings, choose the environment, test the connection.

See Signature providers and TrueSign setup.

Step 3 — The webhook (Yousign)​

In production, the Provision webhook button does everything: creation at Yousign and automatic storage of the secret. Details and the sandbox case in TrueSign setup.

Step 4 — Assign the permission sets​

The package delivers them, you decide who gets what — that is a business choice, not a technical one. See the table of the 10 permission sets.

Step 5 — Create a first template​

At least one active sending template: that is your content, nobody can guess it.

3. If you use weSign — three org settings​

weSign sends emails from your org, which assumes your org knows how to email external people:

  1. A verified sending address (Org-Wide Email Address) — selectable afterwards in Settings. Your invitations then come from "Contracts — ACME" rather than a user's personal address.
  2. SPF/DKIM on your domain — otherwise your invitations land in junk mail.
  3. Setup → Email Deliverability → "All email" — otherwise nothing goes out, with no visible error.

Also mind your org's email quota: usually 5,000/day, but 15/day on Developer Edition and trial orgs — enough to exhaust an afternoon of testing. TrueSign shows the counter in Setup and cleanly refuses a bulk send that would not fit.

4. Options​

  • Automatic placement of tabs and buttons — TrueSign can place its own tabs and buttons. That requires one extra authorization to be established once in your org. Until it is done, nothing is broken: the interface shows the manual placement instructions.
  • AI writing assistance (Gen) — optional, disabled as long as no key is entered. See TrueSign Gen.

5. Checking everything is in place​

The Setup screen carries a progress checklist and a health card: it reports "Maintenance jobs: N/5 scheduled" and offers to re-arm them if one is missing (the operation is safe, it never creates duplicates).

A good verification reflex: the Webhook intake card should show events arriving on your very first test send.

6. Summary​

ActionWhoWhy it is not automatic
Public Site + TES_GuestAdminA Site is not packageable
Provider API keyAdminIt is your secret, negotiated by you
Webhook + secretAdminAn action to perform on the provider's side
Permission sets to usersAdminBusiness choice: who sends, who approves, who reads
Sending address + deliverabilityAdminEmail verification required, org-level setting
First active templateBusinessIt is your content