Salesforce Integration
Salesforce can issue TRUE certificates when a record reaches the right state
Salesforce has no single webhook switch, but it has something better for this: a record triggered flow that can make an HTTP callout when a record reaches the state you choose. Set the condition, point the callout at TRUE, and the person named on that record receives a branded, blockchain secured certificate on your own domain.
TL;DR
There are two ways out of Salesforce and both work. A record triggered flow with an HTTP callout is the low code route and it is what most teams should use. An Apex callout is the developer route, and it is right when the logic is more involved than a flow can express. Either way the connection is authenticated with a named credential, so the token is managed in Salesforce rather than pasted into a flow, and TRUE issues the certificate carrying your design, written to blockchain at the moment of issue.
- Two routes, both standard. A record triggered flow for the low code path, or Apex when the logic needs it.
- You choose the moment. The trigger is whatever change in Salesforce means the credential has been earned.
- Credentials managed properly. A named credential keeps the token inside Salesforce rather than in the flow itself.
How does the Salesforce certificate integration work?
Salesforce holds the record and knows when it changes. A record triggered flow watches for the change you care about and makes an HTTP callout. TRUE takes it, issues the certificate against the matching design and delivers it to the person named on the record.
1
Decide what earned means
This is the real decision, and it is yours. A completed training record, an approved certification, a status reaching a value you already use. Everything else follows from it.
2
Build the flow, or the Apex class
A record triggered flow with an HTTP callout covers most cases without code. If your logic needs more than a flow can express, an Apex callout does the same job. Authentication goes through a named credential either way.
3
Certificates issue themselves
When a record meets the condition, the person receives a branded, blockchain secured certificate with a permanent verification link.
What does the certificate carry?
The recipient name, what they earned, your organisation and the date it was issued, written to blockchain at the moment of issue so it cannot be edited or backdated afterwards.
- Recipient name and credential. Taken from the Salesforce record itself, so it matches what your CRM already says.
- Your organisation. The certificate is branded as yours and lives on your own domain.
- Date of issue, fixed. Written to blockchain at issuance, which is what makes backdating impossible.
- A permanent verification link. An employer confirms it by opening the link or scanning the QR code, without contacting you.
What has to be in place before it can be switched on?
A Salesforce administrator who can build a flow, a trigger condition, and a certificate design. Nothing has to be installed from the marketplace.
- A Salesforce administrator with permission to build flows, or a developer if you take the Apex route.
- A trigger condition, the change that means the credential has been earned. This is the part worth thinking about before you build anything.
- A certificate design, built by us to your profile or adapted by you from an existing template.
What does a recipient receive?
A branded, animated certificate delivered by email, on your own domain rather than ours. It carries a QR code and a permanent verification URL, so anyone can confirm it without contacting you, and it goes onto a LinkedIn profile in one click.
- Beautifully designed. Animated, branded and interactive rather than a static PDF.
- A shareable link. One URL that works in an email signature, a portfolio or a CV.
- QR code verification. An employer, a client or a regulator confirms the credential instantly.
- LinkedIn ready. Added to a profile in one click, which puts your name in front of their network.
- Blockchain secured. It cannot be edited, forged or backdated after issue.
How is personal data handled?
The callout sends only the fields you map into it, which for a certificate is a name, an email address and what the credential is for. Because you build the flow, you can see exactly what leaves Salesforce.
TRUE is hosted in the EU, and we sign a data processing agreement with you before anything is switched on.
How much has TRUE issued for organisations like yours?
More than 500,000 documents for over 200 organisations in 15 or more countries, and credentials shared by their recipients have produced over 100 million marketing impressions. These are TRUE platform figures, not third party research.
500K+ Documents issued
200+ Organisations
15+ Countries
100M+ Marketing impressions
Is a Salesforce record on its own enough?
It proves the record exists in your CRM, which is enough for your own reporting. What it cannot do is prove anything to the person it is about, or to anybody they show it to.
| Capability | The record on its own | The record with TRUE connected |
|---|---|---|
| Proof outside your organisation | The reader has to take it on trust | A permanent verification link anyone can open |
| Tamper proof | No | Yes, written to blockchain at issue |
| Lives on your domain | No | Yes, branded on your own domain |
| LinkedIn shareable | A file to attach | One click add to LinkedIn |
| Effort per participant | Manual handling for anything formal | None, it issues on completion |
| Where the token lives | Not applicable | A named credential, managed inside Salesforce |
| Analytics | None | Views, shares and verifications tracked |
What do Salesforce administrators ask about this?
Mostly whether it needs Apex, whether anything has to be installed and where the token lives. Usually not, no, and in a named credential.
Do we need Apex, or is a flow enough?
A record triggered flow with an HTTP callout is enough for most cases and needs no code. Apex is the right choice when the logic is more involved than a flow can express.
Do we have to install anything?
No. Both routes use what is already in Salesforce. There is nothing to add from the marketplace.
Where does the API token live?
In a named credential, which is Salesforce's own way of holding an external system's credentials. It does not sit in the flow itself.
What should the trigger be?
The change that means the credential has been earned in your process. We work it out with you, because it is a process question rather than a technical one.
Do recipients need a TRUE account?
No. The certificate arrives by email with a unique link. No login, no account and no app.
Can the certificate carry our own design?
Yes. We build the design to your graphic profile, or you adapt one from an existing template. The certificate is branded as yours and lives on your own domain.
Can we issue certificates for records that already closed?
Yes. Earlier records can be issued as a batch, so a backlog does not have to be handled by hand.
What does a recipient do with the certificate?
Share it. It is a link rather than a file, so it goes on a LinkedIn profile in one click and into an email signature or CV, and every share points back to a verification page carrying your name.
Ready to switch it on?
We prepare your certificate design and the exact call the flow should make, you decide the trigger, and the next record that meets it issues a verifiable credential.