Zite apps for Salesforce organizations and HR teams

What Zite is

Zite is an AI app builder. You describe the app in plain language and it generates a working web application, which is then refined screen by screen and rule by rule in an editor. A Zite app comes with hosting, user login (including email one-time codes) and its own database, and it can also read and write external systems such as Salesforce.

That gives Zite two strong fits. The first is a focused app for one process, used by people who do not work in the core system, writing straight into Salesforce or monday.com. The second is a complete standalone business system, with its own data, roles and rules, for a process that does not belong inside a CRM.

What CloudX builds with Zite

CloudX has two Zite systems in production, one of each kind:

• Grant interim reporting connected to Salesforce: grantees of a philanthropic foundation submit a structured, multi-section report that is written straight into related Salesforce objects.
• A multi-company employee evaluation and IDP platform: an HR services organization runs annual evaluations and personal development plans for a number of client companies on one platform, with each company fully isolated from the others.

Both share the same foundation: a Hebrew right-to-left interface, one-time code login, and data scoping enforced on the server, so each user reaches only the records their role and organization allow.

The employee evaluation and IDP system

Several companies, full isolation

One platform hosts several separate client companies. A user from one company sees nothing of another, and each company has its own branding (a color skin), its own allowed email domains and its own usage quota. The platform admin sets up companies, branding and quotas, and never sees an evaluation.

Roles and who sees what

Every role was designed around what it needs to see, and nothing beyond it:

• Employee: completes a self-assessment and builds a development plan with their manager. Sees only their own data, and sees the manager's ratings only after a one-on-one conversation and the manager's decision to share.
• Manager: assesses direct reports, with a view by employee or by competency. Indirect reports appear with their status only.
• HR: runs cycles, questionnaires, employee lists and imports. Sees ratings, manager feedback and plans, but not employees' free text, and not their own evaluation, to avoid a conflict of interest.
• HRBP: sees aggregated data for their own units only, with no names.
• Platform admin: company setup, branding and quotas only.

The evaluation cycle

1. HR publishes a cycle, and every active employee gets an evaluation matched to their job family.
2. Employee and manager rate the same competencies on a 1-5 scale, in parallel.
3. HR locks the cycle, and no further edits are possible.
4. The manager holds a one-on-one conversation, marks it as held and shares the evaluation.
5. The employee sees the manager's ratings and the gap between the two views, in neutral wording and without red warning colors.
6. Employee and manager build development goals together, and both approve them. Changing the aspiration resets the approvals, while status updates and notes do not.
7. HR closes and archives the cycle, and a scheduled deletion date is set according to the retention policy.

Privacy by design

Privacy rules are enforced on the server, not by hiding fields on screen:

• Small groups stay anonymous. The HR dashboard and heat map break results down by department, manager or job family, and any cell with fewer than 3 people is hidden.
• Free text stays personal. HR works with ratings and plans, but does not read what employees wrote in their own words.
• No one evaluates themselves through the back door. HR members do not see their own evaluation, and cannot act on behalf of their own direct reports.
• Exceptions leave a trace. HR can share on behalf of a manager or reopen an evaluation only with a written reason.
• Unknown users get nothing. A login attempt from an unrecognized email gets a Hebrew message and no data.

Built for everyday use

Evaluations are long forms, so the details matter. Every answer autosaves with a clear "saved" status, quick navigation never loses text, and the system warns when two tabs are editing the same evaluation. Each level of the rating scale has a word that describes it, the whole system works by keyboard alone, and the layout is designed for mobile and for right-to-left Hebrew.

HR builds questionnaires in a builder where drafts stay editable and fields lock once a cycle is published, with only one active cycle at a time. Employee lists come in through an Excel import that shows a preview before anything is written, produces an error report, and rejects invalid values and managers outside the company's allowed domains. Locks, shares, reopenings, approvals and imports are all recorded in an immutable audit log.

Before go-live, an external tester runs a full acceptance plan across every role, from employee to platform admin.

The grant interim-report app

Each report section maps to its own Salesforce object, linked to the grant record. The budget section reads the dependent picklist definitions from Salesforce, so the app shows only the values valid for the selected category, and every write passes the org's validation rules.

Grantees log in with their email and a six-digit one-time code and see only their own organization's grants. Staff review the submitted report on the record, where existing reports and automations pick it up, instead of copying sections out of Word files.

Business problems a Zite app solves

• "Grantees send reports as Word files and we copy them into Salesforce." A reporting app writes each section straight to the right records, and staff review it in Salesforce.
• "Annual evaluations run on forms and spreadsheets, and nobody knows who has finished." A cycle-based system tracks every employee and manager through each stage, and HR sees progress on one dashboard.
• "We serve several client companies, and each one must be completely separate." A multi-company platform isolates data per company, with separate branding, email domains and quotas.
• "Employees hesitate to write openly because they are not sure who reads it." Role rules decide exactly who sees what, HR does not read free text, and small groups never appear in reports.
• "We need a new process working fast, without a months-long portal project." Zite gets to a working app quickly, and every app we deliver is security-reviewed and documented before it goes live.

The architecture in plain words

A Zite app is built in layers:

1. The app: screens, forms and logic generated and refined in Zite. This is what users see, on desktop and on mobile.
2. The data: either the app's own database, as in the evaluation platform, or a connection to a core system. A Salesforce connection authenticates as a dedicated integration user whose permission set grants only the objects and fields the app needs.
3. The rules: scoping by user, role and organization is enforced in the app's server-side queries, filtered by the verified login, never only by hiding things on screen.

When the app connects to Salesforce or monday.com, that system stays the single source of truth, and its validation rules, automations, reports and dashboards keep running there. When the app is a standalone system, the same discipline applies inside it: one data model, clear roles and an audit trail.

What users, staff and admins get

For users, the experience is short and familiar: a link, a one-time code, and a Hebrew screen that already shows their own work, whether that is a grant report or their annual evaluation and development plan. No password to forget and no license in the core system.

For the internal team, data arrives in one current place. Foundation staff review reports on the Salesforce record, and HR follows each evaluation cycle on a dashboard instead of chasing forms by email.

For the admin, every app comes with a field mapping document or data model description, so changes are planned, tested in a separate environment, and only then released to users.

How a Zite project runs

1. Process and data mapping: what the app must do, who uses it, which roles exist and which data each role may see.
2. Field mapping document: every field in the app mapped to its object and field, before building.
3. Build against a test environment: the app is generated and refined against a sandbox or test data, never against production data first.
4. Security review: login, server-side data scoping, what the integration user is allowed to do, and file handling.
5. Acceptance across all roles: real scenarios run for every role, in Hebrew and on mobile, before a wider launch.
6. Production and handover: the production connection or data is set up, the field mapping check is run again, and then documentation and a support path.

The security questions we answer for every app

An app that was built quickly still handles real people's data. Before production we answer these questions in writing:

• Who can log in, and how? Secure login, for example email plus a one-time code, limited to known users and allowed domains.
• What can each role see? Data is scoped to the user, role and organization in server-side queries, and we test this by deliberately trying to reach other people's records.
• What is the connection to the core system allowed to do? Only the objects and fields the app needs, through a dedicated integration user, with read or write access as required.
• What is logged and how long is data kept? Sensitive actions go to an audit log, and retention follows the organization's policy.

Choosing a Zite partner: what to ask

• Do they have Zite apps in production, connected to a core system or running as a full business system?
• Who owns the data model and permissions behind the app, not just the screens?
• How is login handled, and how do they prove each user sees only their own data?
• How do they keep an AI-generated app maintainable after the first prompt? Look for a field mapping document and test-first changes.
• Will you receive full documentation at handover?
• Do they build in Hebrew and right-to-left from day one, including accessibility?
• Do they also work with Titan and Experience Cloud, so the recommendation follows the process and not the tool?

How long it takes and what drives cost

A focused app with a few screens is usually measured in weeks, while a multi-role system takes longer and depends on scope; most of the time goes to the data model, security review and acceptance testing. The main cost drivers are the number of objects or entities involved, the number of roles and visibility rules, multi-company requirements, business rules such as evaluation cycles and approvals, imports, file uploads and languages.

Zite vs alternatives

We work with all three, and a Zite app can run alongside Titan when a process also needs generated documents and signature. We recommend the tool that fits the process.

Why CloudX for Zite

• Zite systems in production. Grant interim reporting connected to Salesforce for a philanthropic foundation, and a multi-company HR evaluation and IDP platform for an HR services organization.
• Privacy designed per role. Who sees what is decided before the first screen is built, and enforced on the server.
• The core system comes first. CloudX is a Salesforce and monday.com consultancy, so the data model, permissions and automations behind the app are part of the scope.
• Security built in. Every app gets a review of login, server-side scoping, audit and the integration user before production.
• Specification before building. Even when building is fast, the field mapping and role model come first, so the app can be maintained and extended over time.
• Hebrew and accessibility by default. Apps for Israeli users are designed in Hebrew, right-to-left, with keyboard operation and mobile layout from the start.

Planning a Zite app or a business system on Zite? Talk to us and we will design the right process with you.