Recent updates
-
Creating an Information Box
Updated onArticleAn Information Box enables you to convey instructional information -- such as a warning message or guidance -- to your app’s end users on your transactions’ View Page. This can be an especially helpful tool as it allows you to provide contextual direction to users right when and where they need it.
Developer Tutorials and Materials App Builder Developer Tutorials Customizing the User Interface
-
Making RESTful Calls from Onit
Updated onArticleThis tutorial explains how to set up and configure the Rest Request Action in Onit to interface with external API endpoints. Onit’s Rest Request Action allows you to make GET, PUT, POST, and DELETE actions against an API.
There are many use cases for a Rest Request Action including creating records with a POST, gathering information with a GET, and deleting information with a DELETE request. A Rest Request Action must be utilized with a Business Rule, Button, or Conditional Compound Action (CCA) in order to fire.
To complete this tutorial, you will need:
- An App that you can make changes to.
- An API to call against. In this tutorial we have used a very basic example API named JSONPlaceholder. This API returns sample "posts" from users with a randomly generated title and body.
Developer Tutorials and Materials App Builder Developer Tutorials Integrations
-
Customizing View Pages with Portal Widgets
Updated onArticleOnce created, a transaction is given a View Page. This is a dedicated location where users can work collaboratively on the transaction by viewing Field data, adding comments and files, and much more.
Often times you’ll want to customize the look and feel of an app’s View Page. There are many ways to do this, but one especially helpful way is by using a Portal Widget -- a panel that spreads across the top of a View Page and can be heavily customized using a mix of HTML and Liquid.
Here’s an example of a Portal Widget:
Developer Tutorials and Materials App Builder Developer Tutorials Customizing the User Interface
-
Adding a Participant from a Field Value
Updated onArticleAfter a transaction is created, it will have one or more Participants. These are the people that can view and manage the transaction. Additionally, you can define different Roles that any given Participant will play. For example, you could have a Business Approver Role, which would be assigned specific tasks to complete.
Onit provides App Builders with multiple ways to define exactly who the Participants should be for any given transaction. For some apps, this is simple; If the Participants will always be the same people for each transaction in your app, you can hardcode these users into your app’s configuration. However, some apps’ transactions will conditionally need different participants assigned to them.
One way to conditionally add participants to transactions is to have your requester provide participant information in a Field on the Launch Page. Using a special naming convention for this Field (which we’ll cover in this tutorial), Onit will do a little magic to automatically add a participant into a specific Role using this information.
For example, maybe your Contract Approval app has a Role of Business Approver. When a requester creates a new transaction, you can ask them to select an Participant’s name from a Combo Field. Using the naming convention detailed below, the value for this Field will automatically be added as the Business Approver to the transaction.
In this tutorial, we’ll explain how to add Participants to a transaction using values in a specially named Field.
Developer Tutorials and Materials App Builder Developer Tutorials Building Workflow
-
Creating Loops within Onit Workflows
Updated onArticleThe Looped Actions Action runs a sequence of other Actions, once for every iteration of the loop. This can be handy when you have a variable number of tasks that you want to perform. You must define an iterator and a Condition to specify when the loop should end.
There are three essential parts to configuring a Looped Action:
-
Condition: Defines how many times your loop should run. An example condition would be
Selected Index < Custodian List
Size. This Condition will tell the loop to run as long as the selected index (or iterator) is less than the custodian list size. - Iterator Action: In most cases, your iterator Action should be an Update Transaction Action that increments an integer Field in your App. The iterator must be incremented each time that the loop runs, or the loop will not break and will hit the max loops limit of 999. In addition, you’ll usually want to create a separate Update Transaction action that resets your iterator back to zero this action will run (only once) immediately after your loop starts up.
- Looped Actions: The sequence of Actions that will be run for every iteration of the loop. These Actions will run in the order you specify. One of these Actions should be your Iterator.
In this tutorial we will cover setting up all of the items listed above.
Developer Tutorials and Materials App Builder Developer Tutorials Building Workflow
-
Condition: Defines how many times your loop should run. An example condition would be
-
Collecting Form Submissions from Anonymous Users
Updated onArticleSometimes you will need to collect information from people who are not Onit users. In this event, Onit allows you to send an anonymous portal launch link via email to collect data and create a Record. The anonymous portal launch link allows users to fill in information without logging into Onit. When creating such a link, you can also pre-populate certain fields.
In this tutorial we will be creating an anonymous portal launch link to collect information about a company lunch (which is held once a month). We want our lunch guests to specify their name, if they will be attending, and if they have any food restrictions. We have created a stand-alone App (named Company Lunch) to collect the responses.
Developer Tutorials and Materials App Builder Developer Tutorials Building Workflow
-
Adding Participants from a Decision Table
Updated onArticleAfter a Record is created, it will have one or more participants. These are the people that can view and manage the Record.
In some cases, defining who the participants should be is basic. For example, maybe your App handles approvals, and the approval process always goes through the same three people every time. In this situation, you can use an Add Participant activity, which automatically assigns participants based on either a hardcoded email address that you type in when building the App, or Liquid decision making that outputs an email address.
In other cases, however, deciding which participants should be added to a Record may be significantly more complex. For example, perhaps there are 25 total users that are eligible to become participants on any given Record, and Onit should decide which one to add based on a complex combination of Field values. In this situation, you’ll want to prefer the more robust Add Participants from Table Action over the basic Add Participant Action.
The Add Participants from Table Action uses a Decision Table, which is just a specially-formatted Excel spreadsheet. When Add Participants from Table runs, it queries the Excel file for the participants that map to a combination of Field values, and then adds the appropriate participants accordingly. For example, if the area_of_law is Corporate, and matter_type is Finance, then add Jacob as a participant. If you have lot of Fields, participants, and/or possible combinations, working with a spreadsheet will be much easier.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Spreadsheets and Documents
-
Configuring a Create Related Transaction Button
Updated onArticleHave you built any parent-child or sibling relationships yet in Onit? If so, great! This tutorial will expand your skill set in this area. If not, however, this tutorial might not make a lot of sense -- we suggest taking a look at Creating a Sibling Relationship and Creating a Parent-Child Relationship first.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Records
-
Automatically Creating Child Records
Updated onArticleHave you built any parent-child relationships yet in Onit? If so, great! This tutorial will expand your skill set in this area. If not, however, this tutorial might not make a lot of sense -- in that case, check out Creating a Parent-Child Relationship first.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Records
-
Keeping Field Values in Sync Across Apps
Updated onArticleAfter you’ve configured an app relationship, you’ll likely need a way to keep some of the Field values of those apps in sync. If you updated a Field on a parent transaction, you wouldn't want to have to go through each child transaction and manually update a related Field's value, for instance.
Instead, you can configure an Update Related Transaction(s) Action to keep specific Field values up-to-date with one another. Fields can be kept in sync regardless of whether they share the same name or not.
In this tutorial, we'll walk through setting up an Update Related Transactions(s) Action for Fields in related apps.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Spreadsheets and Documents