Titan implementation · CloudX
Titan implementation on Salesforce: portals, forms, documents and eSignature
CloudX is an Israeli consultancy that builds Titan (formerly FormTitan) systems on top of Salesforce for nonprofits, foundations and organizations in Israel: external portals, smart forms, document generation and eSignature, in Hebrew and English. We design who sees what, what gets created in Salesforce and when, and what happens when something fails. We also take over existing Titan projects that have no documentation and map them into a full specification.
What Titan is and when it fits
Titan (formerly FormTitan) is a no-code digital experience platform (DXP) built for Salesforce. Its portals, forms, surveys, documents and eSignature flows read and write Salesforce records directly, and because it installs as a managed package, everything works on live Salesforce data rather than on a copy. It is a family of products that share one builder:
- Titan Web: multi-page portals with login, tables, dashboards and actions on Salesforce data.
- Titan Forms: forms on the same builder, from a short contact form to a multi-step application.
- Titan Docs: document generation from Word or Excel templates filled with Salesforce data, output as Word or PDF.
- Titan Sign: eSignature, with signing status and the signed file kept in Salesforce.
- Titan CLM: contract lifecycle management on Salesforce data.
- Titan Flow: server-side automation behind a form or portal, such as file processing or calls to other systems.
- Titan Survey: surveys built in Titan, sent from Salesforce, with responses stored there and shown in reports.
- Titan Files: file handling and storage automation around Salesforce records.
Inside every project the core pieces are the same: Get actions that read Salesforce records, Push actions that create or update them, Power Tables for lists users act on, and login options such as SmartV.
Titan is usually the right choice when:
- Salesforce is already the system of record.
- The people using the form or portal are outside the organization, without Salesforce licenses.
- Admins should be able to change a field or a step without a developer.
When the data does not live in Salesforce, or the need is a large community with complex sharing rules, we recommend Experience Cloud, a custom app or another platform during mapping.
What we build with Titan
Buyers rarely ask for Titan. They bring a process that hurts, and most Titan projects we build answer one of these:
- External portals. "Every partner should see only its own data." Applicants, partners, volunteers or customers log in and see only their own records: tasks, applications, grants, documents to sign.
- Multi-step application forms. "Applications arrive as Word files and someone retypes them." A form that saves progress, validates each step and writes to related Salesforce objects.
- Smart intake forms. Find an existing Contact or Account by ID number, phone or email, or create one, so Salesforce does not fill with duplicates.
- Documents and signature. "Signed declarations sit in a shared folder." The document is generated from the record, signed digitally and saved back on it.
- Approval processes. "Our approvals run in Excel and email." A form captures the request, Salesforce holds the status and approver, a Flow moves it forward, and a signed approval document closes the loop.
- A portal inside Salesforce. The same Titan project embedded as a Lightning component, so staff see exactly what the external user sees.
Projects running in production
Bilingual grants portal for a philanthropic foundation
A nonprofit supported by the foundation opens the portal in Hebrew or English and logs in through SmartV, Titan's record-based verification login: the visitor is matched to a Salesforce record, and every Get in the portal is filtered by that verified record. It lands on a task dashboard, applies through a four-step form, and follows "my applications" and "my grants", on mobile as well.
A foundation staff member opens the same record in Salesforce and sees the same portal view, embedded there as a Lightning Web Component. Dashboard figures come from roll-up fields, so they update from the data itself.
Digital driver file for a national nonprofit
A volunteer about to drive for the first time opens the link, enters an ID number and a one-time code, and sees only the volunteer form; employees and family members get their own forms the same way. The form finds the driver in Salesforce or creates a new Contact.
The volunteer reads the declaration, generated from a Word template with their details, and signs it. The signature is mandatory, the signed PDF is saved on their record, and the vehicle department gets an email. In production since July 2026.
Documents generated from a Salesforce Flow
A staff member moves a record to the next stage and finds the document already attached. A Salesforce Flow triggers Titan Docs at that stage, with no button to click. Titan keeps a test version and a published version of each project, each with its own identifier, so we locked which version production calls before go-live.
What applicants, staff and admins get
- External users: a simple login, a form in their language, and a signed document at the end.
- Staff: every submission lands as a Salesforce record with its files and signed document, and staff open the same portal view inside Salesforce that the applicant sees.
- Managers: Salesforce dashboards built on the same data external users enter.
- Your admin: changes are made in the Titan builder, in a test version, and published only after testing.
The security point most portals get wrong
In many Titan portals, the person who logs in is not a Salesforce user. The portal works through a dedicated integration user, and what each visitor sees is decided by the conditions on each data pull (a Get in Titan). If one condition is missing, a visitor can see another organization's records.
The classic gap is a record ID passed in the URL or a hidden field: if a Get trusts that value instead of the verified login, changing one character in the link opens another organization's record. We tie every Get to the logged-in identity and test by tampering with the parameters on purpose.
We map every Get and Push, review the integration user's permissions, and deliberately try to reach another organization's data during testing. On a grants portal for a philanthropic foundation, this mapping found a data pull that could expose one organization's records to another, and we closed it.
Taking over an existing Titan project
Many organizations run a Titan portal whose builder has moved on, and nobody is sure what a given button does in Salesforce. We read the whole project first: every variable, data pull (Get) and update (Push), button action flow, calculated field and document mapping. The result is a written, platform-neutral specification of what the system does today.
With it, the organization decides with confidence what comes next: fix, extend or rebuild. We have used this method on two client projects, and in one it surfaced a security gap that was then fixed.
The same specification protects Salesforce automations whenever forms change. We wrote one for moving an organization's forms to a WordPress portal: a field dictionary plus rules for which actions are update-only and which may create records. The new forms built on it trigger the same Salesforce automations in production.
How a Titan project runs
- Mapping: what exists in Titan and Salesforce, who uses it, and which process it serves.
- Specification: every form, field, Get, Push and button action, approved before building.
- Build in a test version: a draft or sandbox, never the version users are running.
- Testing by user type: permissions, duplicates, both languages, mobile, and attempts to reach other users' data.
- Publish and promote: the approved version moves from sandbox to production with Titan environment variables, so record IDs, template references and URLs point to the right org.
- Handover: documentation, a support guide for your admin, and a defined path for changes.
How long it takes and what drives cost
Timelines depend on scope. A single form that finds or creates a record and generates a signed document usually takes a few weeks. A portal with login, several user types, dashboards and documents usually takes one to a few months, mostly for specification and testing.
The main cost drivers:
- The number of forms, user types and Salesforce objects involved.
- Login and data-separation requirements.
- Documents, signatures and templates.
- Volume: every Get and Push is a Salesforce API call against the org's daily limit, and document generation has its own quota, so high-traffic portals are designed to read less and write in batches.
- Languages, and whether an undocumented project must be taken over first.
We scope after a short mapping session and give a written estimate.
Hebrew, English and right-to-left
Titan serves the same form in Hebrew and English, with right-to-left layout, Hebrew error messages and Hebrew document templates, and we test every screen in both languages and on mobile.
Choosing a Titan partner: what to ask
- How do you scope data per user or organization, and how do you test it? The answer should be specific, not "Titan handles it".
- Do you write a specification before building? Without one, the next change becomes guesswork.
- How do you work between test and production? Building in the live version is the most common cause of broken portals.
- Do you know the Salesforce side as well as the Titan side? Most failures happen on the boundary: permissions, validation rules and Flows.
- Can you take over a project someone else built?
Titan vs alternatives
| Titan | Salesforce Experience Cloud | AI app builder (e.g., Zite) | Custom website portal | |
|---|---|---|---|---|
| Best for | Forms, portals, documents and signature on Salesforce data | Large communities with Salesforce-native sharing and collaboration | Focused apps for people without licenses, on Salesforce or monday.com | Full design freedom, public websites |
| External users need Salesforce licenses | No, in most setups | Yes, community licenses | No | No |
| Changed by an admin without code | Yes | Partly | Yes, by prompt and editor | No |
| Documents and eSignature built in | Yes | Through add-ons | Through integrations | Through integrations |
| Where data-separation risk sits | Conditions on each Get | Salesforce sharing model | App logic and login | Custom code |
Often the strongest answer is a combination, such as a public Titan form alongside an Experience Cloud community for long-term partners. Form tools such as FormAssembly or Jotform fit a single form that posts data to Salesforce; Titan fits when the form is part of a portal, a document or a signature.
Why CloudX for Titan
- We know both sides: Titan and Salesforce. CloudX is a Salesforce consultancy first, so the objects, permissions, Flows and validation rules behind the form are part of the job.
- We document what we build and what we inherit. Every project ends up as a platform-neutral specification.
- We test data separation on purpose, by user type, in Hebrew and English.
- Every build gets an independent check. An independent AI auditor agent checks every Titan build against a defined handoff contract, and a person approves every step.
- We protect your Salesforce automations. Every form change, new build or migration is planned against a field dictionary, so the processes behind it keep running.
Have a Titan portal nobody fully understands, or a process still running on Word files and email? Talk to us and we will start by mapping what you have.
Work we have done
Philanthropic foundation · In production
Bilingual grants portal
The foundation wanted the nonprofits it supports to apply, update budgets and report in one place, in Hebrew and English. We built a four-step application and a portal with a task dashboard, "my applications" and "my grants", with SmartV login and mobile support. The same project is embedded as a component inside Salesforce, so foundation staff see what the nonprofit sees, and the dashboard is fed by Salesforce roll-up fields. When we mapped every data pull in the portal, we found a path through which one organization could reach another's records, and we closed it. Separation between organizations is now tested by user type.
National nonprofit · In production
Digital driver file
The organization needs a signed declaration from everyone who drives its vehicles: employees with or without a company car, family members and volunteers, and each type needs a different form. We built a separate Titan form per driver type, with login by ID number and a one-time code. The form finds or creates the Contact in Salesforce and generates a declaration from a Word template as a PDF with a mandatory digital signature. The signed document is saved on the record and the vehicle department is notified by email, so each driver's file sits in one place. In production since July 2026.
Client projects at nonprofits and foundations · In production
Reverse engineering undocumented Titan projects
Organizations that inherited a Titan system without documentation did not know exactly what a button did in Salesforce, and every change was a risk. We developed a method for reading a full Titan project: variables, data pulls (Gets), Salesforce updates (Pushes), button action flows, calculated fields and document mapping. The output is a written, platform-neutral specification of what the system does today. With the specification in hand, the organization's admin and the next developer know what each button does before changing it, and the choice to fix, extend or rebuild rests on facts. We have used it on two client projects, and in one of them it surfaced a security gap that was then fixed.
Organization running on Salesforce · In production
Titan document generation from a Salesforce Flow
Staff had to remember to generate a document at the right step, and when they forgot, the record moved on without it. We connected Titan Docs to a Salesforce Flow: when the record reaches the defined stage, the document is generated from its template and attached to the record, with no button to click. Titan keeps a test version and a published version, each with its own identifier, so we designed the trigger and the template around that, and the version the team approved in testing is exactly the one running in production. Staff now find the document on the record when they open it.
Organization running on Salesforce · In production
Specification that keeps Salesforce automations intact
The organization decided to move its forms off Titan to a portal on its WordPress site, and the risk was breaking the Salesforce automations those forms trigger. We read the full Titan project and wrote the specification for the move: a field dictionary, and rules that define which actions are update-only and which may create records. The new WordPress forms were built on that specification, and in production they trigger the same Salesforce automations as before.
Internal method at CloudX · In production
AI agent team for Titan builds
Inside CloudX, Titan builds are supported by a team of AI agents. A developer agent builds to an approved specification, and an independent auditor agent reviews the work through a defined handoff contract, without seeing the developer's reasoning. A person approves every step, from specification to promotion to production. For the client, every Titan delivery arrives with an approved specification and a documented independent review behind it.
FAQ
Who implements Titan on Salesforce in Israel?
CloudX, an Israeli Salesforce, monday.com and AI consultancy, builds Titan systems for nonprofits, foundations and companies. We build both the Titan project and the Salesforce side behind it: portals, forms, document generation and eSignature, plus the objects, permissions, Flows and validation rules they depend on. We run Titan projects in production in Hebrew and English, including a bilingual grants portal and a digital driver file with mandatory digital signature. Titan is one of CloudX's platform partners.
Is Titan the same as FormTitan?
Yes. FormTitan was renamed Titan (titandxp), and the product line grew to Web, Forms, Flow, Docs, Sign, CLM, Survey and Files. We work on projects built in the FormTitan days as well as on new ones.
How long does a Titan project take?
It depends on scope. A single form that finds or creates a record and generates a signed document usually takes a few weeks. A portal with login, several user types and documents usually takes one to a few months, with most of the time spent on specification and testing.
How much does a Titan implementation cost?
We give a written estimate after a short mapping session. The main drivers are the number of forms and user types, how many Salesforce objects are involved, login and data-separation requirements, documents and signatures, usage volume against API quotas, languages, and whether an existing project must be taken over first. Titan licenses are purchased directly from Titan.
Titan or Salesforce Experience Cloud?
It depends on the need. Titan suits forms, portals, documents and signature for external users, usually without a Salesforce license per user. Experience Cloud suits large communities with complex Salesforce-native sharing. We have built portals on both and recommend based on users, data and budget.
Titan or Zite?
Titan fits document-heavy portals with several user types, eSignature and admin inside Salesforce. Zite fits focused AI-built apps, including on monday.com. We build with both, and sometimes combine them in the same process.
Titan or DocuSign and Conga for documents and eSignature?
Titan combines the form, the portal, the document and the signature in one Salesforce-connected project, so data an external user enters becomes a signed document on the record without a second tool. Dedicated tools such as DocuSign for signature or Conga for document generation fit when signature or document generation is the only need, or when they are already the standard in the organization. We map the process first and recommend accordingly.
Titan or FormAssembly and Jotform for forms?
FormAssembly and Jotform are form builders with Salesforce connectors, and they fit when the need is a form that posts data. Titan fits when the form is part of a larger process: a portal with secure login, matching existing records, a generated document, a signature, and admin inside Salesforce.
We have an old Titan project with no documentation. Can you work with it?
Yes. We read the whole project, including variables, Gets, Pushes, button actions and document mapping, and produce a full specification before changing anything. From there you decide what to fix, extend or rebuild.
Does Titan support Hebrew and right-to-left?
Yes. The same form can be built in Hebrew and English, with right-to-left layout, Hebrew error messages and Hebrew document templates. We test every screen in both languages and on mobile before go-live.
How do you make sure each organization in a portal sees only its own data?
It is part of design and testing on every portal. In many Titan portals the visitor is not a Salesforce user, and what they see is decided by the conditions on each data pull, so we review every pull, the login and the integration user's permissions. During testing we deliberately try to see another organization's data.
What happens after go-live?
You get project documentation, a support guide for your admin and a defined path for changes. Changes are built in a test version, tested and only then published, so the live version is not broken. Ongoing support with us is available as needed.
Can Titan generate documents and collect eSignatures from Salesforce?
Yes. Titan Docs generates Word or PDF documents from templates with Salesforce data, and Titan Sign adds eSignature. Generation can be triggered from a form, a button or a Salesforce Flow, and the signed document can be saved on the record.
How do we replace an external request-and-approval process run by email and Excel?
Build a form that captures the request directly into Salesforce, keep the status and approver in Salesforce, and move the process forward with a Flow. At the end, an approval document is generated and signed digitally. Titan fits this exactly: the external form, the Salesforce record and the signed approval document are one project.
Do external users need a Salesforce license to use a Titan portal?
In most setups, no. External users log in through Titan's login options, and the portal works with Salesforce through an integration user. That user's profile and permission sets define the maximum the portal can ever read or write, so we give it only the objects and fields the project needs, and never a System Administrator profile. Within that limit, separation between users is set by the conditions on each Get.
Can a Titan portal run inside Salesforce for internal staff?
Yes. The same Titan project can run on a Salesforce page as a Lightning component, so staff see and act on the same screen the external user sees. That is how we built the bilingual grants portal: nonprofits work in the portal, and foundation staff see the same view inside Salesforce.
Last updated: