Key Terms
Kinetic Speak
| Term | Definition |
|---|---|
| Agent | A portion of the Kinetic Platform that sits inside the firewall to execute calls that must take place internally for kinops systems that connect to on-prem systems (such as handlers and bridges). Agent replaced Kinetic Bridgehub and Kinetic Filehub. Agent is the harness that runs bridge adapters and file adapters. It can also be extended to run task handlers in a customer's security context. |
| Application Programming Interface (API) | A software intermediary that allows two applications to talk to each other. |
| Attribute | User-defined metadata for Spaces, Kapps, Users, Forms, Categories, Datastore Forms, or Teams. Also sometimes used as the name for the defined values in a Bridge Model. |
| Bridge | A configured connection to another data source. Bridges are used to pull or push data realtime with other systems. Bridges provide a way for your form builders to interact with another interface to any system with an API in a low-code way. Only platform admins need to understand what connects to what and how to create the queries, and the queries only need to be set up once to be used any number of times. If the data source changes, the references in the individual items don't need to be updated, just the one central resource. |
| Bridge Mapping | The location where the bridge data source is mapped to the bridge model properties. This tells the Kinetic Platform how to get the raw data from the data source, and how to map the source data names to data fields for Kinetic Bridge Models. |
| Bridge Model | A type of object used in Kinetic Platform Forms that is populated from a data source using a bridge to read from that data source. The bridge model allows the object to be assigned properties with normalized names rather than using the original source's cryptic database column names, or some other naming convention known only to the developers of the data source application. |
| Bridged Resource | A defined use of a bridge within a Form. |
| Bundle | Traditional web code that provides the visual interface needed for building out an application. Bundles wrap the forms defined in the Management Author Console and extend functionality your organization needs to build an intuitive, engaging user experience. Bundles typically include items such as theming/branding, search, alerts, portals, and other widgets. Bundles use standard web technologies including HTML, CSS, Javascript, and can be developed using a text editor or IDE. The default bundle uses Bootstrap, but you can include any framework or library of your choosing. Bundles often need server-side access to information about the Kinetic Application including items such as form names, paths to resources, attributes, the authenticated user, etc. This is where the Bundle/Java API comes in. Bundle authors can embed information into their pages through a simple syntax and use helpers to format and present information as needed. Bundles are deployed to the Kinetic Platform web application’s /app/bundles directory, located within a directory named for the slug of the Space where the bundle is to be used. For instance, a bundle for the the Acme space, which would normally have the slug value acme, would be located at /app/bundles/acme/{bundle-name}. |
| Bundle (javascript reference) | Bundle is a helper object designed to be used in javascript applications. The bundle object provides a number of static methods that are automatically included with each request. |
| Connector | The connection between two nodes within a workflow. May or may not contain logic. If logic is applied, the connector path is only followed if the attached logic statement evaluates to not false. Why "not false"? Your connector could return a "Name" of a person - and if a name exists we want that branch of the workflow to execute. |
| Event | An action in the Kinetic Platform. Events cause things to happen. There are internal events and user generated events. An example of a User Event is "Submission Submitted". This event will cause the Kinetic Platform to store the submitted data and pass that data to a workflow to action custom workflow (such as creating a record in the fulfillment system and assigning it to the appropriate team). An example of a System Event is "Form has been created". This event will cause the Kinetic Platform to validate the form definition, store it, and pass that information to a workflow to action custom activity (such as emailing all administrators indicating that a new form exists). |
| Form | Forms are a collection of fields that hold data created by users or system API calls. Forms can have multiple pages and a variety of different field types, such as checkboxes, radio buttons, text, and more. |
| Handle | The last 6 characters of the full submission Id of a record. Provided as part of the record to allow for a more human readable identifier for the submission. Handles are efficiently queried by the Kinetic Platform. |
| Handler | A small program that is able to perform a unit of work. It may take some input values, and usually returns one or more output values. |
| Identity | The object that represents the user currently using the application. |
| Integration | Any connection between the Kinetic Platform and a third-party system. This includes Bridges, files tores, webAPIs, and task handlers. |
| K function | The Kinetic JavaScript library revolves heavily around the K function, which is used as a selector for runtime objects such as the current Kapp, form, or fields on the page. The results of this selection will be Kinetic API objects that can be interacted with. |
| Kinetic App (Kapp) | A collection of Forms within the Kinetic Request CE System. Kapps have their own metadata, categories, webAPIs, forms, and permissions. Typically a Kapp will represent a single end user experience. Example Kapps include a Service Portal or Work Order System. |
| Kinetic Security Language (KSL) | A functional language created for writing and managing security policies. KSL is implemented as JavaScript code. |
| Memberships | Memberships are a relationship between a Team and a User. |
| Node | A representation of a unit of work within a workflow. |
| Qualification | Qualifications represent search queries that can be used to return data from a Bridge. Examples of Qualifications include 'All Active Employees', or 'Location by Site number'. Qualifications are an abstract representation of a query so they only include a name, a setting for number of results (single or multiple), and any parameters. Bridge Model Mapping Qualifications define how a Model Qualification is mapped to a query for a target systems. Mapping Qualifications are typically made up of static search criteria and parameters that are passed when a search is executed. |
| React | A JavaScript library used to build UIs; optimal for fetching rapidly changing data that needs to be recorded. |
| Request | Kinetic Request is the platform component that allows you to build powerful and beautiful front ends for your customers. It contains a drag-n-drop form editor where you can easily construct the forms you wish to present your users, but also supports the complexities of multi-system integrations, multi-tenancy, and workflow integration on all it's components. You may also see this referred to as Request CE, Request Core Edition, CE, or Core Edition. The platform is built with a version of Request (CE) that is entirely our own creation, unlike our previous versions (RE or Remedy Edition) that relied on Remedy to be the platform. Request is the visual point of connection in the platform where Task, Filehub, Bidgehub, and Request itself all come together to provide the customer with the optimal user experience. |
| Routine | A routine is a workflow with specific defined inputs and outputs. Routines are used to define reusable processes that can be used across the system by any Kapp. |
| Security Policy Definitions | A series of definitions that allow administrators to secure the system in a very specific way. Security Policy Definitions have a Name, Type (Form, Kapp, Space, etc…) and Rule. The rule is a KSL expression that should return either true or false and is evaluated at run time when a resource is being accessed. |
| Space | A tenant within the Kinetic Platform. Spaces are a collection of Users, Teams, Security Definitions, Kapps, Forms and all other Kinetic Objects. No data in the Kinetic System is shared between Spaces. |
| Subform | A form/submission that is loaded into the current page. |
| Submission | An instance of a form that contains field values. |
| Submission Activity | A way to attach additional information to a Submission, typically with the purpose of exposing some process details to the original submitter. Often they are used in a Kapps bundle in order to build up a “Submission Details” view. Examples being: "Assigned to User", "Awaiting Approval", etc... |
| Task | The Kinetic Platform component that allows you to build, execute, and handle errors for workflows. It contains a drag-and-drop workflow editor where you connect Handlers (code snippets) together to build your flexible and powerful workflows. There are hundreds of Handlers already built and ready for use; these can connect you with everything from your local Active Directory system to your cloud-hosted AWS provisioning service and everything in between. If your desired integration has an API but no handlers currently available, there are also instructions available for you to be able to build your own. |
| Teams | A way to group individuals within your organization that are working on common projects. Other systems tend to call them Groups ... we think Team is a better name. |
| Tree | A collective process of units of work called nodes. Trees define workflow within the Kinetic Platform. A tree can have nodes, wait states, loops, process gates (wait for these things to all be done), and connector logic. |
| Users | Defined users of the system. Users can be members of Teams. Users can have User Attributes. |
| User Attributes | Attributes attached to a user: location, job title, hire date, etc... User attributes can be used to drive workflow. |
| WebAPI | An entrypoint that can be called from an external process. A defined WebAPI will have a workflow attached that will run when the WebAPI is called. |
| Webhook | A user-defined HTTP callback to a third-party application that is fired when some predetermined action occurs. Data that corresponds to the action, such as a form being submmitted, will be sent to the webhook URL as an HTTP Post action. |
| Webhook Jobs | An instance of a webhook tied to a specific record (Submission, Form, User) that was created due to an action occurring on the record. |
| Workflow | A tree or routine. A process that does the work for a given event. Sample events: Submission Created, User Defined, Form Modified, etc... |
Updated over 1 year ago