Recent updates
-
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
-
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
-
Generating a Word Document
Updated onArticleWith Onit you can leverage Record data to generate Microsoft Word documents. The Generate Document Action relies on Liquid markup in a pre-built template to query Record data and insert it in the appropriate location. For instance, if your App manages Non-Disclosure Agreements (NDA), you could generate a document that contains Record-specific data (such the other party’s name to the agreement, its effective date, etc.) for each NDA Record in your App. This allows you to essentially use Onit as a publishing tool. In this tutorial, we’ll first explain how to build the Word template and then we'll explain how to configure the Generate Document Action. Finally, we'll wrap up by showing you how to generate a table of child data in your Word document.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Spreadsheets and Documents
-
Generating a Spreadsheet
Updated onArticleOnit can generate Microsoft Excel spreadsheets that contain data from Onit transactions. For example, maybe you’d like to offer your users the ability to click a Button in Onit to generate an Excel spreadsheet on-the-fly. The generated spreadsheet could contain all transactions of a certain type -- one row per transaction. You could also add columns to the spreadsheet that would hold each transaction’s Field values. In addition, you could format and structure the spreadsheet to look however you like. The Onit Action that provides this functionality is Generate Spreadsheet. It’s one of the more advanced Onit Actions, so in this tutorial we’ll explain its basic configuration. The Action’s more advanced options will be covered in a separate tutorial.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Spreadsheets and Documents
-
Using a Spreadsheet to Organize Tag Logic
Updated onArticleTags are used to control the display of sets of Fields. However, the Update Tags UI Action you can use to implement them has its limitations; you very well may find yourself needing a better way to organize your Tag activation conditions. An Update Tags Using List Lookup UI Action allows you to tidy up your Tag logic in an Excel spreadsheet and comes in handy when: You have a large number of Tags and your App’s business logic around which Tags should be activated becomes more complex. You’re applying multiple levels of Tags whose activation depends on independent determining Fields’ inputs. You need to apply a separate UI Action to a Field also serving as a determining Field for a Tag’s activation conditions. In this tutorial, we’ll walk you through how to use a spreadsheet to organize your Tags so you can easily apply multiple Tags to independent determining Fields.
Developer Tutorials and Materials App Builder Developer Tutorials Working with Fields