Product10 September 2026, 11:22

ICanUp Forms Became Part of a Unified Communication Center

ICanUp gained reusable forms with dynamic fields, server-side validation, and anti-spam protection. The key architectural decision is that form inquiries become conversations and messages in the shared Communication domain instead of a separate inbox.

Once ICanUp gained Services and About pages, the next natural step was allowing visitors to do more than read information and contact the project directly.

Instead of creating several independent contact forms for different pages, ICanUp introduced one reusable Forms architecture.

The same foundation can support project inquiries, service requests, support, and future communication scenarios.

One Form can be reused in multiple places

Reusable Forms

A Form exists as its own managed entity and can be embedded on multiple Pages without duplicating its fields.

Dynamic Fields

Administrators can configure text, textarea, email, select, and checkbox fields.

Field Ordering

Fields can be reordered and are rendered according to their domain-defined sequence.

Two Locales

Labels, help text, options, submit text, and success messages support Ukrainian and English.

Forms became standard ContentBlocks

A configured Form can be embedded into any Page through the standard ContentBlock pipeline.

The block stores only a Form reference and presentation configuration. Fields, translations, and validation rules are not copied into every Page.

Updating the Form in Admin therefore updates every place where that Form is used.

Presentation supports controlled variants including a card, a media-and-form split layout, and a background treatment. Field layout and submit button alignment can also be configured at block level.

Submissions are validated on the server

Dynamic Validation

Validation rules are resolved from the current Form definition rather than relying only on browser-side constraints.

Unexpected Fields Rejected

A public request cannot silently submit values that are not part of the selected Form definition.

Anti-Spam Protection

Rate limiting and lightweight anti-bot controls reduce automated unwanted submissions.

Data Minimization

Only the required page, locale, and visitor context is propagated without storing unnecessary raw request data.

Submissions enter the shared Communication domain

After successful validation, ICanUp does not create a separate Form-specific copy of the message.

The system creates or resolves the appropriate conversation, while the actual inquiry becomes a Message in the existing Communication domain.

The conversation receives controlled context describing the Form, source Page, locale, visitor context, and inquiry type.

This makes it possible to reuse existing unread state, realtime updates, permissions, and conversation workflows without duplicating them for Forms.

One center for different inquiry types

Project Inquiry

The About page can accept inquiries about a project, idea, or potential collaboration.

Service Inquiry

The Services page can receive project and service inquiries through the same Forms architecture.

Support

Support requests use the same Form and messaging foundation while keeping their own source and context.

Unified List

Administrators see these inquiries alongside other conversations and can filter them by source.

Context belongs to the conversation

The Communication Center needs to know not only what was written but also where the conversation came from.

A shared source and context contract distinguishes direct chats, form inquiries, service inquiries, support, and other communication scenarios.

The message body is not duplicated, and adding a new source does not require another conversation table or a separate Admin inbox.

The full flow is tested end to end

The Forms feature is tested as a complete flow rather than only as isolated components.

Automated coverage follows the full path: Form configuration → Page embedding → public rendering → validation → submission → conversation → Message → Communication Center presentation.

Guest and authenticated submissions, inactive Forms, abuse protection, authorization boundaries, and the absence of duplicate message storage are covered as part of the integration.