Zoho Creator pricing for internal apps and vendor portals

Your inspection app has five internal reviewers, but the next person who needs access works for a supplier. Zoho Creator pricing separates the employee roster from the portal users outside the organization. Before approving the subscription, specify what that supplier can submit, which records they can read, and whether other vendors must remain invisible.

Evaluate Standard for one application whose limits cover the work. Consider Professional when you need more applications or capacity, and Enterprise when its additional scope is required. Obtain a separate portal-cost confirmation for the external roster. Keep an existing application if it already meets the access requirements and moving would mainly recreate working forms and scripts.

Separate the application from its two audiences

A Creator application combines forms, reports, pages, and workflow logic. A portal provides an entry point for external users, such as vendors, to access shared application components. Signing into a portal establishes identity; permissions still determine the records and actions available to that person.

For an inspection workflow, define the vendor identity, inspection reference, submission status, and reviewer decision before building screens. A trusted result needs the supporting record and the rule used to reach it. A status labeled approved should have a specific meaning, such as acceptance of a submitted inspection record, rather than implying payment or authorization to perform unrelated work.

Kartik Deshpande prepared this review from official sources checked October 22, 2026. The figures use the published USD listings, subject to confirmation for your billing region and account. The acceptance exercise is proposed, not a firsthand product test. The enterprise app development article covers the broader work of defining the application and its owners.

Calculate five internal users over twelve months

Zoho’s Creator pricing page lists annual-billing USD rates of $8, $20, and $25 per user per month for Standard, Professional, and Enterprise. Its official platform comparison also publishes monthly-billing rates of $12, $30, and $37. Local taxes are additional.

These calculations assume five licensed internal users remain for the full period. The annual column represents the yearly billing commitment at the displayed rate, not a monthly cancellation arrangement. Neither column includes portal capacity, implementation, custom development, premium support, or third-party subscriptions.

Standard lists one application, while Professional and Enterprise list unlimited applications. Other limits still apply. Request the expected record count, file storage, integrations, schedules, and API use in the proposal; do not assume unlimited applications means every resource is unlimited. The Power Apps pricing comparison shows why the same user roster must be carried into another vendor’s licensing model.

Price the external roster as a separate requirement

The pricing page offers a customer portal add-on, but the applicable user band and commitment for this example have not been established. The complete vendor-portal total therefore remains unknown. Ask Zoho to quote the named internal plan, the number of external users, the number of portals, and the billing period together.

Zoho’s portal-user documentation says adding a user to two portals in one Creator account counts both additions toward the portal limit. Model that overlap before estimating the external roster. A supplier contact who works across projects may not correspond to one counted portal membership.

Also ask how suspended users, seasonal access, and roster changes affect billing. Keep any unanswered amount visible as a quote requirement. Buying only employee seats would leave the external-access cost unresolved, and treating every vendor as an employee without checking the licensing rules would change the scenario.

Inspect the default portal permission set

The Creator 6 portal-permission documentation describes module and field permissions, including separate View all and Modify all actions. It also describes a default Customer set that can expose records added by all users. Review the assigned set before inviting vendors; do not infer isolation from the presence of a login page.

The documented model distinguishes a user’s own records from all records. If several contacts at one supplier should share company records, that is a different access requirement from each person seeing only their own submissions. Specify the organization relationship and prove the intended behavior rather than broadening access to all vendors.

Zoho lists plan-dependent portal permission-set allowances. Count the distinct access patterns the application needs, then confirm the edition covers them. Where environments are enabled, the documentation says permission changes reach live portal users when the application is pushed to Production. Include that publication step in the access-change procedure.

Test a vendor submission and an internal review

Create a permitted sample with Vendor A and Vendor B, one external contact at each, and the five internal reviewers. Add an inspection form containing vendor identity, inspection reference, result, attachment, and review status. Keep the reviewer’s decision and internal comments separate from the vendor’s submitted facts.

Have Vendor A submit inspection A-01. Its user should see the submitted record and permitted status, but should not edit the internal decision or see Vendor B’s record. Have a reviewer request a correction, then let Vendor A revise the allowed fields. Preserve enough evidence to distinguish the submitted information from the later review outcome.

Repeat as Vendor B and inspect reports, search, and any enabled export path. Test a direct attempt to reach the other vendor’s record through supported navigation or a known record link. Hiding a row in one report is insufficient if another permitted route exposes it. Record the observed result instead of assuming the permission configuration worked.

Finally, remove one vendor’s access, publish any required permission changes, and verify denial in the live test environment. Confirm which records an internal reviewer can export. This exercise establishes an acceptance target; it does not claim Creator passed in a configuration that has not been tested.

Separate application structure, records, and connections

Zoho’s DS-file documentation describes an export of the application structure, including forms and Deluge workflow code. It excludes stored records and certain images used in pages or print templates. Importing that file alone does not restore the inspection history.

Use the appropriate data export or application backup for records and files, then test restoration into a permitted destination. Reconcile record IDs, attachment links, reviewer decisions, and vendor relationships. Review connections and credentials through supported configuration rather than copying secrets into scripts.

Moving to another builder also requires a plan for Deluge logic, interface bindings, and access rules. A Creator structure export is not evidence that another runtime can execute it. The AI app builder comparison helps frame that choice, but repeat the same vendor-isolation exercise after any rebuild.

Where Permute fits around the inspection evidence

Permute sells connected business data and custom applications. A suitable project could reconcile permitted vendor records, operational data, and inspection exports while retaining source references. Begin with the vendor identifiers and the definition of an accepted inspection so different reports apply the same rule.

An operations reviewer could then inspect which submission and decision support a reported status, with missing evidence left visible. Access must reflect the current user and application scope. The implementation needs to establish source access and freshness before anyone treats the result as operational.

Confirm the migration and action boundaries

Permute is not presented as a one-click Creator migration or a ready-made Creator connector. App logic and portal permissions require their own implementation scope. Any external action must be separately authorized and permissioned; a report about an accepted inspection does not itself approve payment.

Budget the five internal users using the billing term you intend to buy, then add a confirmed portal quote. Select the edition after the application limits and access patterns are known. Prove vendor isolation and export behavior with the sample before inviting the full roster. Keep the existing app when it meets those requirements without a costly rebuild.

Questions about Creator subscriptions and portals