🗃️ Configuration Studio
3 items
📄️ Form Settings
Every form in Shesha has a set of Form Settings that control three things: how the form looks, how it loads and saves data, and who is allowed to use it.
🗃️ Security
6 items
📄️ Audit Logging
Audit logging keeps a record of what changed on your data, when it changed, and who changed it. In Shesha this record is called the audit trail, and it lets you answer questions like "who deactivated this user?" or "when was this application submitted?" without writing any extra code.
📄️ Background Jobs
A background job is a piece of work that runs separately from the user's request, so the user does not have to wait for it to finish. When someone clicks a button that starts a slow task, you queue that task as a background job and let the user carry on while it runs.
📄️ Expose & Module Hierarchy
Shesha applications are built on top of base modules, such as the framework's own modules and any shared product modules your organisation maintains. Those base modules ship their own configuration items, like forms, reference lists, and entities. The Expose mechanism lets you customise those base items inside your own application without changing the base module, and the module hierarchy decides which version of an item wins at runtime.
📄️ Configuration
Shesha is a low-code platform, which means a large part of how an application behaves is defined through configuration rather than written in code. Forms, reference lists, settings, and more are set up by configuring them instead of programming them. Because so much of the application lives in configuration, understanding how configuration is managed, and especially how it is moved between environments, is essential.
📄️ Custom Notification Channels
This guide explains how to extend Shesha's notification framework with a custom delivery channel, such as Slack, Microsoft Teams, or WhatsApp. If you only need to send notifications through the built-in Email and SMS channels, see the main Notifications page instead.
📄️ Entity Configuration
Entity Configuration lets you control how each entity in your application behaves directly from the front-end, without changing code. Entities are one of the configuration item types managed in the Configuration Studio, alongside forms, reference lists, roles, and permissions. Because they are configuration items, entity configurations can be exported and imported between environments in the same way as other Shesha configuration items.
📄️ File Storage
Storing, displaying, and managing files is a common need in business applications, and Shesha provides built-in file management to handle it. These features include:
📄️ GlobalState
GlobalState in Shesha is a shared store of values that any part of your application can read from or write to. It is useful when one component needs to react to something that happened in another, without passing values through every component in between.
📄️ Changing the Home Page
After a user logs in, Shesha redirects them to the home page at the / route by default. This page explains how to change that destination, either to a fixed URL for everyone or to a different page per user based on their role or other criteria.
📄️ Modules
Shesha promotes a modular approach to building applications. Instead of building everything from scratch, you package reusable functionality as Shesha modules and assemble those modules to deliver solutions efficiently. Shesha modules are distributed as regular NuGet packages and implement the SheshaModule class.
📄️ Notifications
Shesha provides a built-in notification framework for sending messages through multiple channels such as Email, SMS, and Push notifications. The framework is designed to be:
📄️ Scheduled Jobs
Many enterprise applications require that certain actions are performed in the background and triggered on a set schedule (e.g. every night, every week, or even every few minutes). We call these Scheduled Jobs and build on top of Shesha's support for Background Jobs. Such operations may include:
📄️ Specifications
A specification is a named, reusable, combinable, and testable filter for an entity or other business object. The Specification Pattern lets you wrap a piece of filtering logic in its own class so you can apply it to queries and operations across your application instead of repeating the same where clause everywhere.
📄️ Validation
Where Should Validation Logic be Implemented? On the Application or Domain Layers?