A collection of short videos, how-to's and other resources to help you get building great solutions faster.
Kinetic Request helps you create intuitive, beautiful front-end customer experiences for complex back-end processes across your enterprise from IT to HR and beyond.
Typical use cases include:
Form Authors use the Kinetic Request form builder, an intuitive drag+drop interface, for creating dynamic, data-driven forms including data validation.
Form Authors also handle any form attributes like costing, service owner, service description and more. They also handle categorization of forms for easy navigation in environments with many services.
Bridges make data from external data sources such as LDAP or Salesforce or another database accessible to your Form Authors without any coding. This bridge data can drive menus, defaults, personalization, and more.
Process Authors use Kinetic Task to handle the back-end processing and fulfillment once a form is submitted. This could include things like looking up approvers, interacting with a CMBD, pushing data to a case management system, triggering emails, setting SLA milestones, or triggering fulfillment forms to subject matter experts.
A Kinetic Task process (called a Task Tree ) is triggered via a Webhook. Webhooks send structured data from Kinetic Request to Kinetic Task related to the original form submission on an event. Events include things such as a form submission or form update. Kinetic Task then takes that data and runs the tree related to that form submission. Each node in that tree (we call them handlers) does a specific task to complete the process. Processes can be linear or involve many branches and dynamic paths to completion.
Kinetic Task is bundled with Kinetic Request and also can serve as a stand-alone integration and workflow hub for a variety of situations.
System Administrators handle the creation of permissions, users, and other configuration.
Spaces are tenants within the application. No data is shared between spaces including users. Many organizations will have a single space. Service Providers may have multiple spaces in a single application instance to manage their various discreet customers.
Kapps are individual Kinetic Applications within the space. Within your default space you may have multiple Kinetic Request Kapps, possibly for different catalogs or a playground vs. published services.
Kapps are created, users are managed, and other Space-wide configuration is done via the Space Administration Console, accessible via the menu on the top-left hand side of the application to authorized users.
Kinetic Core is the platform that Kinetic Request is built on. Kinetic Core manages centralized logging, data persistence, authentication, authorization, data validation and more. This specific version of Kinetic Request being run is Kinetic Request Core Edition (CE). You will see some references to “Core” functionality within some of the documentation.
Explore the rest of our documentation to take your skills to the next level.
We have a full set of in-depth documentation to learn more about how our products work here: