Core Concepts Explained

To effectively design and build applications on Struktural, business analysts and developers must share a common vocabulary. The following are the foundational building blocks of the platform.

1. Tenants (Multi-Tenancy)

A Tenant represents an isolated instance of an application. In a B2B SaaS context, each of your corporate customers would be a Tenant.

• Isolation Strategy: Struktural handles multi-tenancy at the data tier. While all tenants share the same underlying server infrastructure and codebase, their data is strictly isolated using dedicated database schemas (e.g., tenant_acmecorp.Customers).
• Configuration: Each tenant can possess distinct configurations, including different Identity Providers (Entra ID vs. Google), isolated File Storage buckets, and specific Secret Manager Vaults.

2. Entities

An Entity is the fundamental data structure in Struktural. It represents a business object (e.g., Invoice, Employee, Vehicle).

Persistent Entities

These represent physical tables in the underlying SQL database. When you define a Persistent Entity, Struktural automatically manages the primary keys, foreign keys, indexes, and constraints. They are subject to the full ACID (Atomicity, Consistency, Isolation, Durability) guarantees of the database.

Virtual Entities

Virtual Entities are data structures that exist only in memory; they do not create tables in the database.

• Use Cases: They are primarily used to construct complex, multi-step UI Wizards, to aggregate data for custom Dashboard reports, or to serve as Data Transfer Objects (DTOs) when mapping data to and from External APIs.

Metadata Fields (EAV)

Certain business domains require dynamic data structures (e.g., products with varying specifications like "Screen Size" or "Horsepower"). Struktural supports Metadata fields, which implement an Entity-Attribute-Value (EAV) pattern under the hood. This allows end-users to define custom attributes at runtime without requiring a developer to alter the database schema.

3. Workflows (Asynchronous Orchestration)

A Workflow represents a background business process. Unlike synchronous actions that happen immediately while the user waits, workflows are designed for long-running, multi-step orchestration.

• Triggers: Workflows can be initiated by data events (e.g., "After an Invoice is created"), on a recurring schedule (e.g., "Every Friday at 5 PM"), or via incoming HTTP Webhooks.
• Stateful Pauses: A workflow can safely pause its execution to wait for a specific date, a duration, a data change, or human intervention (User Tasks), resuming seamlessly when the condition is met.

4. Custom Actions

A Custom Action represents a discrete, synchronous operation triggered directly by a user interacting with the UI.

• Implementation: It surfaces as a button in the frontend (e.g., "Approve Leave Request", "Calculate Total").
• Execution: Clicking the button executes a targeted C# script on the server. The execution blocks the UI momentarily and provides immediate, real-time feedback (success messages, validation errors, or UI navigation commands) to the user.