Enterprise AI Workflow Platform with Integrated Data Privacy Neutralizer
This document provides an overview of the PowerOn platform architecture, building blocks, and capabilities for external software developers who want to contribute to or integrate with the platform.
PowerOn is a Multi-Agent AI Platform for Enterprise Workflows with an integrated data privacy neutralizer. The platform enables companies to accelerate their AI transformation without data privacy risks.
React-based playground UI as entry point. Additional UIs (chatbots, customer UIs) can be easily integrated via REST API in React, JavaScript, or other languages.
RESTful API providing full access to platform capabilities. Open API design allows external UIs and integrations.
Core orchestration engine managing tasks, actions, and state. Supports multiple execution modes (Learning, Actionplan, Automation).
Modular service architecture with specialized services for AI, data processing, security, and integrations.
Multi-tenant database with RBAC-based access control. Mandate isolation ensures secure data separation.
For each customer journey, a workflow can be configured in the workflow editor where:
Plug & play architecture for document renderers. Support for multiple formats (PDF, DOCX, XLSX, PPTX, HTML, Markdown, JSON, CSV, etc.) with easy extension capabilities.
Intelligent AI model selection per intention type. The system automatically selects the best AI model based on the task: analysis, generation, web research, planning, etc.
PowerOn enables customers to transition from application-centric to data-centric work. This is a key differentiator that transforms how businesses operate.
Work with customers to identify their key customer journeys and business processes that can benefit from automation and AI.
Start with a simple MVP that integrates customer data sources with strong focus on data privacy and compliance:
This step builds trust and demonstrates the platform's commitment to data security.
Deploy a pre-processing engine at the customer's location using a standard API:
This step further enhances data privacy and gives customers full control over their data processing.
Gradually integrate additional components until the customer works data-centrically instead of application-centrically:
This transformation is a KEY DIFFERENTIATOR! Customers no longer think in terms of applications, but in terms of their data and business processes.
The core building block is workflow elements: tasks with actions. Each workflow consists of tasks, and each task contains one or more actions that execute specific operations.
Definition: Top-level container representing a complete customer journey or business process.
Purpose: Orchestrates multiple tasks to achieve a business goal.
Definition: A logical step in the workflow.
Purpose: Groups related actions that work together to complete a sub-goal.
Definition: Executable unit that performs a specific operation.
Purpose: Actions belong to methods (microservices) and are the atomic units of work.
PowerOn supports three execution modes, each optimized for different use cases:
Best for: Exploratory tasks with up to 5 steps
Approach: Iterative Plan-Act-Observe-Refine loop
Use Case: When the solution path is not fully known in advance
Best for: Structured, sequential processes
Approach: Batch planning with sequential execution
Use Case: When the workflow steps are well-defined
Best for: Repetitive, predefined workflows
Approach: Automated execution (scheduled or event-triggered)
Use Case: Production workflows that run automatically
Workflow methods provide actions that can be executed within workflows. Each method exposes multiple actions accessible via self.services.<method>.<action>:
All microservices are accessible via self.services.<serviceName>. Services follow a consistent access pattern and are organized into logical categories.
Complete overview of all available microservices:
self.services.chat - Chat and conversation management
self.services.workflow - Workflow state and managementself.services.utils - Utility functions (timestamps, formatting, etc.)self.services.ai - AI model management and operations
self.services.generation - Document generation
self.services.extraction - Document extraction and processing
self.services.neutralization - Data privacy neutralization
self.services.sharepoint - SharePoint integration
self.services.web - Web operations
self.services.ticket - Ticket system integration
self.services.security - Security operations
Examples of how to use services in workflow actions or methods:
# In workflow actions or methods
result = await self.services.<service>.<method>(parameters)
# Example: Using AI service
response = await self.services.ai.process(prompt="Analyze this document", documents=[...])
# Example: Using SharePoint service
files = await self.services.sharepoint.searchFiles(pathQuery="sites/my-site/documents")
# Example: Using generation service
document = self.services.generation.createDocument(format="pdf", content={...})
The Role-Based Access Control (RBAC) system provides complete UI configuration per tenant and user. It enables fine-grained control over data access, UI visibility, and resource availability.
Table and field-level permissions for database operations. Control who can read, create, update, or delete specific data.
Component and feature visibility management. Configure exactly which UI elements each user or role can see.
System resource availability control. Manage access to AI models, actions, and other platform resources.
For DATA context, the system uses opening rights with four access levels. These levels determine what data a user can access:
No access - item is completely hidden/disabled
My records - only records created by the current user
Group records - records within the same mandate (group context)
All records - full access to all records in the mandate
The view attribute controls visibility and enablement. This is the fundamental on/off switch for all RBAC contexts:
Key Rule: Only objects with view: true are shown. This applies to:
The RBAC system uses a cascading hierarchy where more specific rules override generic ones:
item = null) - Apply to all items in contextitem = "table.field" or item = "ui.component.feature") - Override generic rulesResolution Logic: Within a single role, the most specific rule wins. Across multiple roles, opening (union) logic applies - if ANY role enables something, it is enabled.
For DATA context, read permission (R) is a prerequisite for create/update/delete operations (CUD). This ensures data integrity and proper access control:
Key Rule: You can ONLY create/update/delete if you have read right.
RBAC rules apply to three different context types, each serving a specific purpose:
Database tables and fields. Controls read/create/update/delete permissions.
Example: item: "UserInDB.email"
UI elements and features. Controls component visibility.
Example: item: "playground.voice.settings"
System resources (AI models, actions, etc.). Controls resource availability.
Example: item: "ai.model.anthropic"
The Playground serves as the main entry point and demonstration UI. It's built with React and provides a comprehensive interface for workflow interaction:
The UI is completely configurable via RBAC rules. This allows customers to configure exactly the UI they need for their use case:
This allows customers to configure exactly the UI they need for their use case.
Additional UIs can be easily integrated via the REST API. All UI components communicate with the platform through the standardized REST API, ensuring consistent behavior and security:
All UI components communicate with the platform through the standardized REST API, ensuring consistent behavior and security.
The platform provides reusable UI components that can be configured via RBAC:
PowerOn is designed as a vendor-independent platform regarding AI models:
Universal connector architecture supporting all major platforms:
Customers are not locked into a single vendor ecosystem.
Future capability to graphically model workflows for customer journeys:
This makes workflow creation accessible to business users, not just developers.
Integration of PowerOn actions as MCP (Model Context Protocol) plugins in the customer's Copilot:
This enables customers to leverage PowerOn's powerful workflow capabilities directly from their familiar Copilot interface.
The platform exposes a comprehensive REST API for all operations. This API serves as the primary integration point for external developers:
Developers can extend the platform by creating custom components in these areas:
Create custom workflow methods by extending MethodBase and registering actions.
Extend the services layer by creating new service modules following the existing pattern.
Build connectors for external systems (databases, APIs, services) using the connector interface.
Create React components that integrate with the REST API and respect RBAC rules.
Follow these steps to get started with platform development:
Main directories where developers can add new functionality:
gateway/modules/workflows/methods/ - Add new workflow methodsgateway/modules/services/ - Add new microservicesgateway/modules/connectors/ - Add new connectorsgateway/modules/routes/ - Add new API endpointsgateway/modules/features/ - Add new features