Primary Elements from a Developers Perspective
- Updated on 03 Apr 2019
- 5 minutes to read
Primary Elements Overview
Decisions provides a number of different design tools, to create different executable artifacts designed to be used by people who are not programmers. The design tools are all graphical and self validating, however, from a developers perspective its important to understand what each of these pieces are and how they all fit in with other elements.
Flows are configurations that sequentially process a number of flow steps to get work done. Flow steps are pieces of .NET code that are plugged into the application via interface that execute what they were designed to do. Flows are things that designers build, a sequence of steps that are chained together that pass data from one to the other to execute business logic. Can be as simple as adding two numbers together, or creating tasks/assignments or heavy asynchronous or synchronous user interactions. Flows are composed of steps that are like methods and flows themselves become API endpoints callable by any developer. Flows can also be chained together, one flow can call another flow and handle the results of the other flows. Flows can be secured, the access to both use and edit the flow can be altered.
Rules are conditional logic crafted in if/then/else statements (statement rule), or more dense rule types like truth tables and matrix rules. Rules are stateless declarations of policy calculation decisions making, where data is presented to the rule and the rule will result in some data or action being taken but they are always stateless. Flows can be used to tie rules together and provide states in a long running transaction. They can be presented in a number of different forms depending on how a user wants business logic to be evaluated. Rules can be called as an API, can also be combined together into composite units called, Rule Sets, that allow users to have a number of rules to provide a much more complex and new answer to a problem.
Reports and Dashboards
Decisions includes the ability to aggregate and view data in a way that's consumable. Using reporting and dashboards, data can be reported on both inside Decisions and outside Decisions in the same environment. All the reports have the ability to have action context established on them, actions can be made on data from within a dashboard. They can be called via API. Decisions supports reports in an external reporting system and external analytic systems but using built in Decisions means you're inherently tied to that workflow actions can be expose easily and readily.
It is important to establish the right structure, storage, and context. Can be created using SDK or can be created in the user interface by tools that bring in JSON and XML Schema. If you point to the database table that will create data structures. Having a web service return will crate data structures. As well as, the user interface gives the ability to define data structures. Theses data structures are passed flow to flow, rule to rule and provide the business logic by which decisions are made and data is aggregated. Data structures created in the tool can also be stored directly in our database in a normal table/column format, decisions maintains that for you. There are are few special kinds of data structures available within decisions that you can create.
Entities live within the portal and have the ability to attach actions to it. (i.e. : doc entity, download/update document) Most things that you see within the portal are entities, accounts and folders for example. Any entity has the ability to declare what actions can be taken on it. Meaning that entity looks at the current user and current state and based on the current state and current user gives a list of actions that the user can do. The UI is driven by the action context. Entities track who changed it and when it's changed automatically in the database. Therefore, there is extra auditing data that’s always available about the entity as well as the state. By default, entities live in a folder which gives them a security context. All this data can be reported on.
This is the structure of a rule, flow, page, report stored within an entity in the portal. When users create a flow, there's an entity called “element registration” that is created and stored in the database, in a table called “Element Registration”. Editing the flow is an action, running the flow is an action. Decisions is based on an entity model, also able to be leveraged in your custom application code.
Some designers are intended to design user interfaces for end users to integrate with:
Pages allow the user to view and interact with data that is not currently moving through a flow. All User Interface elements are style-able via .CSS or .LES, so they can conform to your corporate styles.
There are two types of integration, integrating with an external system to so decisions can use that integration within a rule or a flow. The second type is having another system call decisions, which is known as API. Building integrations users will create one of three main objects: data type, flow step, or rule verb. Can be built by the administrator, if there is a service based or data structure based integration capability on the external system. Directly in the portal. It's important to understand integration will result in a new flow step able to be used by the designer. If the user is integrated with Salesforce there will be a number of steps in the steps panel enabling the user to take particular actions with Salesforce. An Integration is complete when steps exists in the steps panel to be able to use in the flow engine.