If you’ve worked your way through the Explore and Intermediate tutorials, then congratulations! You’re nearly complete with the first Building an Event Manager tutorial series.
In this chapter, our focus will shift on unexplored features and how you can leverage your new skills to get the most out of Ninox.
The topics that we’ll be working on together include:
Ready? Let’s do it!
Tables within Ninox can be viewed as either a PDF or as a web page (HTML format) for printing. Let’s have a look at how to do this.
Start by navigating to a table.
Select the Gear icon.
In the drop-down menu, select Print View.
By default, the table will display as a PDF format directly on your screen or your browser will download the PDF (as shown below).
In addition to PDF format, Ninox supports displaying a table as a web page (HTML format) which can then be printed. You can also change the text size used!
Start by navigating to the Tables screen.
Select the wrench icon—in the upper right corner—to go into Admin mode.
Next, select the Options tab.
In the window that appears there is a section called Printing Tables…
In the Font size field, change the value to make your text larger or smaller, as needed.
In the Preview as field, you can change from the default PDF format to HTML, which displays a table directly in your web browser.
After changing the printing option to HTML, you can proceed to viewing the table on a web page and then printing it.
To view in HTML format, just follow the same instructions earlier for “Printing a Table”:
…and then right-click on the web page and select Print… (this process may differ based on your browser and/or operating system — Windows 10 using Chrome is shown here).
In addition to printing tables, you can also print one or more individual records. This is done by using the Print icon when viewing a table. Let’s do a walkthrough of this process together.
The first step is to look at how to select records. There is a slight difference between an active record row and a selected record row:
Why is this important? Ninox uses your selections to present printing options for you. Let’s do a quick print, then look at our options in more detail.
Start by making one row active—just select a row and it will turn blue!—and then select the Print icon:
After doing this, the Print screen appears. In the upper-right, select the Print icon and then—in the drop-down menu—select either This record or All (x).
Selecting “This record” prints only the active record — Ninox prepares a PDF and your browser will automatically initiate the download process.
Selecting “All (x)” prints all records — as above, Ninox prepares a PDF for download.
Let’s try a different way. This time, make 1 row active (“Bioderm Ltd” in the graphic) and choose 3 different rows (“Allstar Sports”, “Otis Manufacturing”, and “Radargus” in the graphic) by selecting row numbers.
Then select the Print icon:
Like before, the Print screen appears. In the upper-right, select the Print icon and then—in the drop-down menu—select either This record or All (x).
Selecting “This record” prints only the active record (“Bioderm”), regardless of whether it was selected or not.
Selecting “All (x)” prints all selected records (“Allstar Sports”, et al).
If you want to print ALL records, just make one row active then select the “All” option; alternatively, you can select every single record in the table.
If you want to print SELECTED records, select them by clicking the row numbers and then select the “All” option.
If you want to print just the ACTIVE record, make the row active and then select the “This record” option.
When printing, you can select paper format and margin values to customize your printouts — note that all measurements are in millimeters. In addition, the document width & height fields are auto-populated based on the paper format selection.
As we discussed in the last Intermediate tutorial, tables can be referenced with each other to create more ways to integrate information.
In the example that we worked on, we created a reference from the Events table to the Company table. This enabled us to select a company that was associated with an event — each event could only be associated with one company, but each company could be associated with multiple events.
As a reminder, here’s the Events form. Notice the Company field at the bottom — one company is associated with one event:
…and here’s the Company form. Notice that two events are associated with one company:
In this example, a company can sponsor many events, but an event can only have one company sponsor at a time.
This type of table relationship is called a “1:N Relation,” which means that one data record from one table is assigned (related) to many data records from another table.
From the Tables screen, select Data Model to get a visualization of this relationship (make sure that your red Admin wrench is selected!).
Here’s what it looks like for the Events and Company tables discussed above:
In this relationship, the Events table is a “child” of the “parent” Company table.
In a 1:N Relation like this, there is no cause-and-effect between the tables… deleting a record in one table has no effect on records in the other table. The two tables simply share data between each other.
In some scenarios, though, you may want to create a cause-and-effect relationship.
For example, if a table populated with telephone numbers is referenced to a table with contact details, then we could create a deeper cause-and-effect relationship between them: when a contact record is deleted, then the associated telephone numbers in the other table would be deleted as well (since the numbers no longer have a purpose on their own).
This type of cause-and-effect relationship between tables is called Composition.
Ninox’s composition feature empowers companies to build robust datasets that can reflect accurate, real-time information.
But let’s not get too far ahead! First, let’s do a step-by-step walkthrough to see how the composition process works.
Using the knowledge you picked up in the Intermediate tutorial, create two tables called “Telephone Numbers” and “Contacts”. The former is a simple 1-column table comprised of just telephone numbers. The latter is also a simple table with first name, last name, and maybe some basic company details.
Here’s a look at our new “Telephone Numbers” table:
We formatted the Telephone default value field to “+1” and also limited the number of characters to 12 (+1 plus 10 digits). Here’s what it looks like:
…and here’s a look at the new “Contacts” table:
Start by creating a table reference from the Telephone Numbers table to the Contacts table. Do not Save yet!
At this stage, we have created a 1:N Relation between both tables. Now, we will turn on the composition feature:
Select the newly dragged-and-dropped Contacts field.
In the Composition field, select Yes.
Finalize process by selecting Save changes.
A peek at the new data model shows a distinctly different visualization:
In this composition relationship, the Contacts table is now a “super table” with the Telephone Numbers “sub-table” fully integrated within it.
Due to this new composition relationship, when a record in a supertable (Contacts) is deleted, then any associated records in the sub-table (Telephone Numbers) are also deleted.
Let’s see this in action.
First, we will open the Telephone Numbers sub-table and assign two numbers to the contact, Mr. George Sanderson:
If you need a reminder on how to do this, here is a visualization:
Next, we’ll have a look at the contact record for Mr. George Sanderson in the Contacts supertable. Notice that the two numbers are listed at the bottom:
Since there is a composition relationship, when we delete Mr. George Sanderson from the Contacts supertable, then the two associated telephone number records will also be deleted:
A composition relationship between tables is best used when sub-table records (e.g., telephone numbers) are closely tied to a supertable record (e.g., a contact) and their deletion will not adversely affect any other data.
Another example is an invoice item—such as a client-specific ID number—that is directly tied to an invoice. If an invoice record is deleted, then the invoice item will be deleted as well.
Ninox enables companies to exercise a great degree of control over how users can interact and use the solution. This is supported by a robust user management system that allows Admins to control access for team members as well as granular access over tables and even fields!
In Ninox, there are two types of default roles available:
Admin: Can create new databases, change the data model, and manage users.
Editor: Can edit and delete databases.
When you create a new team, you are automatically the Admin of that team. Remember in the Explore tutorial we talked about how to invite other users to your team? During that process, you, as the Admin, can define what role the invited user will have.
Here’s a reminder:
By default, Ninox offers Admin and Editor roles, but you can also create your own role — these customized roles are used when specifying access to tables and fields.
To start, let’s explore how to assign rights at the table and field levels.
Ninox enables Admins to implement high-level permissions as well as more detailed granularity when it comes to granting rights to both tables and fields.
For tables, Admins can assign rights to user roles for all tables as well as specific tables.
Let’s demonstrate this process by creating a new role for a new user and then applying rights to that role.
First, invite the new user by selecting Invite from the Database screen.
Select Create new role.
In the Role name field, enter a name for the new role — in this example, we’re using “QA Analyst.”
Select Send invitation.
The invitee will receive an invitation via e-mail with a link. When this link is selected, the user will be prompted by Ninox to formally accept the invitation:
If you need to assign rights on a larger scale across all tables, then do the following:
From the Team Workspace screen, select a database. The Tables screen appears.
Select the red Admin wrench icon on the top right.
Select the Security tab.
In this panel you can choose which roles have access to specific rights by selecting a drop-down arrow and then choosing 1 or more roles. By default, rights are assigned to all users (“everyone”) when no choices are made.
When done, select Save changes and then OK to confirm.
You also have the option of assigning rights to roles for individual tables. Let’s do a walkthrough of this process.
Navigate to a table.
Ensure that the red Admin wrench icon is enabled (on the top right).
Select the Gear drop-down icon and, in the sub-menu, select Edit fields…
In the table panel, modify rights drop-down menus as needed.
By default, if no role if selected, then all users have access to the right.
Rights options available include:
Allowed to read: Selected roles can view/read table records.
Allowed to write: Selected roles can change/write table records.
Create new Records: Selected roles can create new records.
Delete Records: Selected roles can delete records.
Readable if and Writable if: Admin can enter code that enables user-based conditions for reading/writing tables (not covered in this tutorial).
At the highest level of granularity, you can specify rights at the field/attribute level. Here’s how to do it:
In the Fields panel, double-click/select a field. The Field Detail panel appears.
Select More options.
In the Allowed to read field, select one or more roles to enable field read access.
In the Allowed to write field, select one or more roles to enable field write access.
Great work! Now that you’ve mastered Roles & Rights, let’s explore the topic of Triggers together.
Triggers are powerful tools that enable you to introduce a level of automation in your Ninox tables and fields. A trigger is just a way of saying, “When x happens, do y.” or “When this happens, do that.”
Triggers can be used in a variety of ways, such as:
Copying values between tables.
Automatically changing values when something happens.
Automatically retrieving data from a linked table, and so on.
If you are designing your own app, it’s good to rely on a formula whenever possible, but there are times—such as the need to create new records or pull data from a linked table—that a trigger will be your best option.
There are two places in Ninox where triggers are implemented: at the table level and at the field level.
For this tutorial, we will look only at table-level triggers and how they can be used to introduce automated record updates.
A table-level trigger launches a specific code set either when a record is created (“Trigger on create”) or when Ninox updates a parent record and it will affect a child record (“Trigger after update”).
Let’s do a walkthrough of how a trigger can be used to automatically update an invoice number whenever a new record is created.
Imagine that we have a table that consists of invoices where every new record is a new invoice. Instead of manually typing in the next relevant invoice number, we can use a trigger to tell Ninox to automatically assign an invoice number for us.
Walkthrough: Auto-increment Invoices Based on the Last Record
Start by creating a simple table called “Invoices” with a Number field called “Invoice Number”. It should look like this:
Edit the table (i.e., select the Gear icon and then select Edit fields…) and, in the Edit Table screen, select the Trigger on create field.
The Code Entry screen appears.
The field Trigger on create is where we define a trigger. The trigger is activated whenever a new record is created in the table.
The Code Entry screen is used to enter Ninox code that can trigger events. In this case, we will enter a code that automatically increases the Invoice Number field by 1 whenever a new record is made (based on the number of the last record).
Enter the code below into the white content panel of the Code Entry screen:
Here is the code for easy copying & pasting:
let i := number(last((select Invoice).’Invoice Number’));
‘Invoice Number’ := i + 1
On line 1, we are defining the variable “i” by finding the last record within the field (“Invoice Number”) from the table (“Invoice”).
On line 2, we tell Ninox that the number field “Invoice Number” should equal our variable “i” plus 1.
Let’s finish it up by selecting OK. The OK button will work if the code is accurate/valid. If not, a warning message will appear stating the part of the code that will not work.
In the Edit Table screen, select Save changes.
Now, for testing.
In the animated graphic below, every time we select the plus icon (add new record), the value in the Invoice Number field increments by 1.
Here’s what it looks like if we start with Invoice Number 1800:
…but this method just increments the last-entered invoice record. It does not auto-increment based on the most recent invoice record (that is, the invoice with the highest invoice number).
This could cause a problem when an old invoice is edited and its number changes to the most recent invoice number. When a new record is created, its number will be based on the last entered record and not the most recent record (the one that was edited).
Here’s a visualization of the problem:
In the graphic above, the most recent invoice is number 24 (row 3), but when we add new records, the trigger tells Ninox to increment based on the last entered invoice… which is number 5 (row 5).
Fortunately, fixing this issue is straightforward via a simple code change.
Instead of looking at the “last” record:
let i := number(
((select Invoice).’Invoice Number’));
…we will look at the “max” record — the record number that is the maximum, or has the highest, number:
let i := number(
((select Invoice).’Invoice Number’));
So just replace the phrase “last” with the phrase “max”. Here’s what it looks like in the code editor:
With this new code in place, let’s see what happens when we add a new record:
As you can see, Ninox now looks at all Invoice Number data, determines which one has the highest value (most recent), and then auto-increments new records based on that number.
The “Trigger after update” feature has a specific purpose: it is used in a child table and is designed to update records after Ninox updates a parent record.
We will discuss how to use this feature in upcoming tutorial content.
Thanks to Zapier connections, Ninox is able to integrate with a number of robust software solutions. One of these is Integromat, an online automation platform that enables users to connect multiple applications and substitute manual processes with automated workflows.
If you use Integromat, then you can connect Ninox to monitor, list, retrieve, lookup, create, update, or delete records and files in Integromat as well as list teams, databases, and tables in your Ninox account.
From the Team Workspace, select the Gear icon.
In the drop-down menu, select Zapier Integrations and then, in the Zapier Integration window, select Generate.
After selecting Generate, an API Key will appear. Copy the character string to your clipboard.
Open the Integromat solution and, in the Dashboard, select Create a new scenario.
In the Integration screen, select Ninox and then select Continue.
Select the question mark icon, select Ninox, and then select Get Record. The Ninox dialog box will appear. Select Add.
The Create a connection window appears.
In the Connection name field, enter a unique name for the Integromat/Ninox connection.
In the API Key field, paste the API Key from your clipboard.
In the Private Cloud URL field, enter your Ninox Private Cloud URL (if you are hosting).
Select your Ninox Team, Database, and Table.
When done, select OK.
Ninox and Integromat are now connected! You can use Integromat to automate many of your favorite Ninox features, such as these:
You’ve not only just connected Ninox with Integromat, but you have completed the Independent Tutorial as well! Great work!
Please continue to watch our online documentation as we continue to find ways to engage and foster success for users of all levels.