The default authentication flow requires users to pick their unique username and password when signing in. Some systems offer to enter email or phone number as a username instead. XM^ONLINE provides an alternative to both and allows customers to sign in using multiple login identifiers. Anylogin functionality enables customers to sign in the system using a username or email address, or phone number (plus password, of course). Customers are free to insert any of pre-configured login types into login form’s username field. By default XM^ONLINE offers three ways of authentication: Email and Password Phone number and Password Username and Password Besides users are able to sign in for XM^ONLINE using their social network credentials, such as Linkedin, Facebook, Google, Twitter. Anylogin is an out-of-the-box authorization mechanism that is available to all customers by default. Once system user has specified his username, phone number, email at the system account settings he can use any of this information as login credentials.

Multitenancy is an architectural feature of XM^ONLINE allowing to provide a dedicated space (tenant) for each customer. The multitenant architecture allows customers to get a dedicated software with its data, configuration, individual functionality, user management and access rules. Such multitenant approach provides a possibility to various customers use XM^ONLINE common environment in own way, since each of them having a dedicated secure space. Each tenant is isolated and invisible to other tenants so customers do not have a feasibility to access each other's data. Information security is supported on the architectural level – the distinction between the tenants has been accomplished during the solution design. The Multitenancy provides a high level of customization to satisfy company’s needs. XM^ONLINE supports customization of the user interface, business logic, workflow and access control.

Attribute-based access control (abbreviated as ABAC) is an authorization model that provides dynamic, context-aware and risk-intelligent access control. ABAC evaluates available descriptive data (attributes) against stored policies to determine whether the user is authorized to access the requested resource. This authorization model helps XM^ONLINE users to configure larger and more definitive set of rules to express tenant access policies. For example, with the help of access-control model it is possible to set the rules, like: User A can access all entities of his company. User B can access all entities of his department. User C can access entities he created. In ABAC each separate action is evaluated against the attributes of entities (subject and object), operations, and the environmental conditions relevant to the request, while other access control paradigms consider each request in terms of isolated user role and the type of action that need to be performed. ABAC advantages Easy to understand and configure permissions mechanism. Effective control over the number of rules and conditions so it is easier to maintain. Access control permissions are evaluated in real-time when actual request is made. Ability to add attributes based on the existing infrastructures. This approach has no restrictions: users can apply the rules of any complexity, including those that contain some unknown attributes. Due to the comparatively clear business logic and compact configuration ABAC makes it possible to avoid many of the costs associated with maintenance when implementing complex rules and provides absolute control over the actions and data inside the tenant, making it ideal for dynamic projects with rapidly changing requirements.

A domain object is a concept that represents an entity from a domain model related to the software and implements the business logic of its work. For example, the software solution for orders management can contain such domain objects as "order", "order item", "invoice". Domain objects encapsulate the information about the entity in the business domain, which is necessary for the software, that makes it understandable for non-technical people, such as business representatives. XM^ONLINE entities are created and configured dynamically within a tenant, where an administrator can specify and flexibly configure attributes, lifecycles and their relationships with other entities (domain objects) to cover customer’s problem area. This approach lets a customer avoid the hard-coding of all service functionalities and their possible compositions at design time, delaying their refinement until the execution phase. If you’d like to learn more about XM^ONLINE domain objects read our article ‘How to specify domain objects’.

The Balance Management provides activities related to the creation and maintenance of the balances of a customer and/or a subscriber. Balances may be shared (e.g. between subscribers in a hierarchy). Types of balances include: Monetary balances Non-monetary balances (e.g. free unites, quota, tokens, etc.) The balance management supports the definition of policies per balance or balance type. Policies include: Minimum Allowable Balance limit (e.g. balance must remain above zero). Balance expiration dates. Balance thresholds actions and notifications. Balance management operations include: Unit reservation from a balance for a specified interval (session). Unused units are credited back into the balance when the session is released. Release of reserved unit Balance prioritization based on policy/rules Balance inquiry. Support for multiple simultaneous sessions that affect a common balance. Splitting charges between multiple balances. Application of a payment to a balance. Communication of balance information to the financial systems (e.g. General Ledger, Accounts Receivable) within the enterprise. A balance (B) usually consists of a single value only. Its use is not directly restricted by specific periods of time. Instead it is only indirectly restricted through the rules the balance is used in. For credit balances, however, it might be required that a balance consists of one or more values: with its own period of availability (which may then be further restricted by the rules the balance appears in) or marked with a label to identify a specific portion of a balance Such a value with a certain validity period or a specific label is called a pocket (P). The validity start and end of a pocket can be configured based on date level, so that the validity of a pocket starts on day x at 00:00:00 and ends at day y at 00:00:00 or date and time level, so that the validity of a pocket also depends on the time of day, so when the pocket is created on day x at hh:mm:ss, the validity ends on day y at the same time on hh:mm:ss. In the example, the value of the balance B3 is the sum of the values of all pockets P1, P2 and P3, which are valid at this point of time.

LEP is a middle between the need for time-consuming full development and low-code/no-code platforms with pure visual tools. Many startups and enterprises focused on delivering applications for innovation, customer engagement, operational efficiency, or legacy migration are recognising the inherent business value and time-to-market advantages of using simple scripting coding (based on the Groovy). XM^ONLINEwith LEP functionality for application development that employ declarative techniques instead of programming are available to customers at low- or no-cost in money and training time to begin, with costs rising in proportion of the business value of the platforms. There are several important drivers: Operation-driven development LEP offer more intuitive ways to build applications, minimising the use of coding. This approach enables a range of users - from professional developers to citizen developers. Reusability Productivity can be further accelerated with LEP that promote reusability through out-of-the-box templates, plug-ins, business components, and connectors to emerging technologies. Support beyond the build phase XM^ONLINE with LEP are designed to support the entire app lifecycle: design, build, deploy, manage and iterate. Cloud-native deployment XM^ONLINE offer the flexibility to deploy and manage applications in the cloud of your choice, or even on premises. Offering automated deployment along with a cloud-native, stateless architecture enables out-of-the-box high availability and fail over to support large-scale deployments, particularly in an enterprise context.

A dashboard is a visual display of the most important information needed to achieve different objectives, arranged on a single screen, so the main information can be seen at first sight. In other terms, they are a collection of widgets that give an overview of the most important data. XM^ONLINE, allows to create multiple dashboards, which, helps to navigate faster through the System and allows to configure dashboards, for different users. For example, simple user can have access to only certain dashboard, while other user, to the other one. Also, dashboard logic depends mainly on the business task. A widget is a mini-report that can display your data in a number of different presentation styles, including simple graphics, charts, tables. On the specific dashboard, they can show information about bookings, revenue or completed tasks. Widgets, can be different. For example, Stats Widget can give the information about number of active accounts and, in the same time, about number of cars. The thing is, that they can be the same type, but they give different information, from different applications, for different dashboards. Widgets can contain not only plain static numbers, but also, they can perform different active functions. For example, Tasks Widget, where you have functionality such as adding tasks, changing reminders, creating events, editing and completing tasks is available straight from your home screen. There are widgets that can not be configured, while others can be for specific client needs, like: Welcome Widget Sign-in/Sign-up Widget Entity Widget Stats Widget General map Widget Weather Widget Clock Widget News Widget Markdown Widget Tasks Widget Entities list Widget

A timeline diagrams present events during specific intervals shown chronologically along a line. Timelines are used as a control and monitoring tools. They can highlight important events and required information in the current context to provide additional information on how the process can be optimized and therefore increased. As an example of timeline, it can be a history of the bank operations. It can include different operations (cash withdrawal, payments, receipts and other business transactions). The start point can be the first transaction of account, the last point will be the most recent transaction. It allows to see how money are moved through account and for what reason. A timeline implemented in the XM^ONLINE is a presentation tool which is displayed most important events that occur in the System relating to the specified entity. Events in timelines are tied with each other and they can be aggregated. Besides timeline can be displayed for any element of the System whether it is timeline of entity or timeline of menu. Timeline in the XM^ONLINE allows the next things: sorting by tags, for quicker search of problems, important information that happened in a certain time or the other things that can be useful for customers; configuring to display only important changes with an entity; configuring to display changes of some special functionality; tuning displayed events such as: technical data of person who changed (browser, operating system); business data (transactions, fulfilling orders); logic data (what was changed and why); configuring how to display events (ways of notes, ordering, icons).