How Your Application Works

Before you learn any particular screen, it helps to know the shape of the thing you are using. This chapter builds that picture: what your application is made of, the two screens you will spend almost all your time on, and why your colleague's version of the same screen may not look like yours.

Read this one first. Every other chapter in this guide assumes the words and ideas introduced here.

What You Are Actually Using

Your application is a working business system — orders, customers, projects, tickets, whatever your organization does. Underneath it sits a platform called Jetstack, which supplies the parts every business system needs: screens that list things, screens that show one thing, forms, files, searching, permissions.

The important consequence is this: somebody decided how your application looks and behaves. That person is usually called your administrator, or the people who set the application up. They decided:

• which kinds of information the application holds (customers? invoices? inspections? applicants?)
• what each of those has to record (a customer has a name, a billing address, an account manager…)
• which screens exist, what they are called, and where they live in the menu
• which columns appear in a list, in what order, sorted how
• which buttons exist and what they do
• who is allowed to see and do what

None of that is fixed by the platform. Two organizations running on the same platform end up with applications that share almost no vocabulary and no screens.

Why This Guide Describes Things You May Not Have

Because everything above is a decision rather than a rule, this guide has to describe the full range of what is possible. You will read about a control and then look for it and not find it. That is normal, and it usually means one of three things:

1. Your application was set up without it. A list can be configured with no Add button, no filter panel, no export menu.
2. Your role does not include it. See Roles, Groups And Permissions.
3. The feature is licensed separately and your organization has not enabled it. Features that are not enabled do not appear at all — there is no message, no grayed-out entry, nothing.

For the same reason, this guide is careful about names. Where a label is fixed by the platform, it is quoted exactly. Where the label is something your administrator typed, the guide describes the control by what it looks like and where it sits instead. If a name in this guide does not match your screen, trust your screen.

Example This guide talks about "the Add button above a list." In one application it reads New order; in another it reads Register applicant; in a third it does not exist at all because orders arrive from a website and nobody creates them by hand.

The Two Things You Work With

Almost everything in your application is one of two ideas.

A Record

A record is one thing: one customer, one order, one task, one job applicant, one invoice. It is the unit you open, read, edit, and send to somebody.

A record is made up of fields. A field is one labeled piece of information — a name, a date, an amount, a status, an attached file, a checkbox. When you open a record you are looking at its fields laid out on a screen. When you edit a record you are filling in those same fields on a form.

Every record also carries a title — one of its fields is designated as the thing that identifies it. That title is what appears in list rows, in breadcrumbs, at the top of the record, and in links to it from elsewhere. For a customer this is normally the company name; for an order it is more often an order number.

Records also carry information you did not type: when they were created, when they were last changed, and who changed them. If your application keeps that tab available to you, it appears on a record tab named Activity; see Record Detail Screens.

A Record Type

A record type is the kind of thing a record is: Customer, Order, Task, Invoice. All records of the same type have the same fields, the same screens, and the same buttons, because they were configured once for the type and then apply to every record of it.

This is why the platform can behave consistently even though your application is unique. Your administrator defined the Order type once — its fields, its list screen, its detail screen, its buttons — and every order you will ever open follows that definition.

Record types are usually named in your own business language, and both a singular and a plural name exist ("Order" / "Orders"), which is why a button might read New order while the menu entry reads Orders.

Example A distribution company has record types Customer, Order, Order line, and Delivery. "Acme Ltd." is a record of type Customer. Order 2026-0417 is a record of type Order. The four lines on that order are four records of type Order line. All orders look the same on screen because they share the type; a customer looks completely different because it is a different type.

The Two Screens You Live In

Nearly every screen in your application is one of two kinds.

The List Screen

A list screen shows many records of one type at a time: all your open orders, all customers in your region, all tickets awaiting a reply. This is where you find things, sort them, narrow them down, and pick the one you want.

A list screen can be drawn in one of several layouts, and the layout changes how the same records look:

Which layouts a given screen offers is decided when the screen is built. Many offer exactly one. When a screen offers several, an icon button above the list opens a short menu headed Viewer, and you pick the layout you want from it.

The layouts are not interchangeable in what they let you do. Checkboxes for selecting several records at once exist only on table layouts, for example. Each layout has its own chapter in Working With Lists.

Around the records themselves, a list screen may also carry a filter panel, a saved-view switcher, a column picker, an Add button, action buttons, and paging controls. All of those are optional and are covered in List Screens.

The Detail Screen

A detail screen — the record detail — shows one record: its fields, its related records, and its buttons. You get there by clicking a record's title in a list, by using the menu on its row, or by following a link to it from another record. Clicking anywhere else in the row does not open it.

A detail screen is usually organized into tabs. One of them — normally the first — holds the record's own fields; others may hold its history, lists of related records, or purpose-built pages your administrator designed. Which tabs exist is part of the record type's configuration, so Order and Customer will have different tabs.

The full anatomy is in Record Detail Screens.

How You Move Between Them

Opening a record from a list normally does not take you away from the list. Instead the record slides in from the right as a pop-up window over the list, and closing it puts you back exactly where you were, with your filters and your page position intact.

Pop-up windows stack. Open an order from a list, then click the customer named on that order, and you now have two pop-up windows on top of the list. Closing the customer returns you to the order; closing the order returns you to the list.

Records can also be opened as ordinary full pages, which is what you want when you need a plain link to the record itself. See Pop-Up Windows.

Example You are working through a list of overdue invoices. You open invoice 4417 — it appears as a pop-up window over the list. Its customer is "Acme Ltd."; you click that name and Acme's record opens on top. You check Acme's payment terms, close that window, close the invoice, and you are back on row seven of the same filtered list. Nothing was lost.

Modules: How Screens Are Grouped

A module is a named area of the application. Modules are what you see in the navigation — the left-hand menu, or the tile launcher if your application puts navigation across the top.

A module normally opens one screen: a list of orders, a dashboard-style page, an overview built for a particular team. Modules can be nested, so a parent module such as Sales can contain Orders, Quotes, and Customers. Some entries in the navigation are not clickable at all — they are section headings that only group the entries under them.

Modules are how your administrator turns a pile of record types into something that reads like your organization. There is no rule that one module equals one record type; a module can show a screen that mixes several, and one record type can appear in several modules.

Two practical consequences:

• A missing menu entry is not necessarily a missing feature. Modules can be restricted by role and can be switched off entirely. If a colleague has an entry you do not, compare roles first.
• The navigation only shows what you may open. There are no grayed-out entries. If there is no module you are allowed to open, you may land on a module-selection page that says "No modules available" and advises you to check your permissions or contact your system administrator.

The navigation itself — pinning it, resizing it, the top bar around it — is covered in The Application Window.

Records Are Connected To Each Other

This is the idea that makes a business application more than a set of spreadsheets, and it is worth slowing down for.

A field does not have to hold text or a number. A field can point at another record. The Customer field on an order does not contain the words "Acme Ltd." — it contains a pointer to the Acme record. That is why the customer name on an order is a link you can click, and why correcting Acme's address once corrects it everywhere.

A field can point at one record or at several. An order points at one customer; a project might point at five team members.

Because pointers exist, three things follow that you will meet constantly.

Related lists appear inside a detail screen. If order lines point at their order, then the order's detail screen can show a list of its lines — a complete, filterable list screen embedded in a tab. Opening a customer and finding a tab full of that customer's orders is the same mechanism.

Links go both ways, but you have to look in different places. The records this record points at are on its own fields. The records that point at this one are gathered in a tab labeled "Mentioned in" by default, which your administrator can rename or remove. Most business records have nothing there, which is normal — it only fills up when other records reference this one, whether through a field or through a comment.

Deleting is heavier than it looks. A record that other records point at is not an isolated thing. See Deleting Records And The Trash.

Example An account manager opens Acme Ltd. Its Overview tab shows Acme's own fields, including a Account manager field pointing at a user record. A second tab, added by the administrator, shows every order placed by Acme — that is a list screen inside a detail screen, with its own filters and paging. A third tab, "Mentioned in," shows a support ticket that referenced Acme in a comment.

Buttons That Navigate, And Buttons That Do Something

Buttons in your application fall into two groups, and telling them apart saves a lot of hesitation.

Buttons that navigate. They take you somewhere: open a record, open a form, open another screen, open an external website. Nothing changes as a result. The Add button, a link to a related record, and the entry that reopens a record on its own page are all in this group.

Buttons that act. They do something to data or to the outside world: send an e-mail, approve a request, generate a document, mark something complete, produce an export file. Your administrator builds these to match your process, so their names are entirely local: Send to customer, Approve, Generate delivery note, Recalculate.

Action buttons live in three places: in a menu labeled "Actions" at the top of a record, in a row of buttons across the top of the record's content, and in the right-click menu on table rows. Which of the three is used is a configuration choice, and one action can appear in more than one place.

Some things worth knowing about action buttons before you press one:

• Some ask for confirmation and some do not. A confirmation is something your administrator adds deliberately. Its absence does not mean the button is harmless.
• There is no undo. Not for actions, not for edits, not for deletions. If you are unsure what a button does, ask before pressing it rather than after.
• A button may do something you cannot see. Actions can be set up to work with records you have no access to — a Submit for approval button can create an approval record in a queue you will never see. This is intentional, not a fault.
• Some entries are not buttons at all. An entry can be marked as information only. In the Actions menu it renders as plain unclickable text; in a row of buttons it renders as a button you cannot press. Either way it exists to tell you something about the record, not to do anything.

Exports are a particular kind of action and behave differently from the rest — they run in the background and deliver a file. See Action Buttons And Exporting.

Your Role Decides What You See

Every user account holds one or more roles. A role is a named bundle of permissions, and it is the single biggest reason two people looking at the same screen see different things.

A role controls, independently:

• which modules appear in your navigation
• which record types you can list at all
• which records within a type you can see — a role can be limited to "only records where you are the owner," so the same list legitimately shows you eleven rows and your manager four hundred
• which fields are visible to you, per record
• which buttons and actions you get, including whether you may export a given record type
• which tabs a detail screen offers you
• which application-wide capabilities you have, such as search, notifications and your own dashboard

Roles add up. Holding two roles gives you everything either of them grants; a role can never take something away that another role gives you.

The thing that surprises people most is that being denied usually looks like emptiness rather than an error. A list you may not read renders as a normal, empty list with the screen's own "no data" message, which reads "No data match the query." unless your administrator replaced it. A field you may not see is absent — not blank, absent. A button you may not press is missing from the menu rather than grayed out. So "there's no data" and "I'm not allowed" look identical from the outside.

Two more practical notes:

• A field can also be set to disappear when it is empty. That is a choice made per field rather than a general rule, so an absent field may mean you are not allowed to see it, or it may mean nobody filled it in.
• A change to which roles you hold takes effect at your next sign-in. Your roles are read when you sign in and stay fixed for that session. If an administrator has recently given you a different role and nothing has changed on screen, sign out and sign back in.

The full model, and a diagnosis checklist for "my colleague can see this and I cannot," are in Roles, Groups And Permissions and Why Your Screen Differs.

What Is Yours And What Is Everyone's

Some of what you see is a shared, configured part of the application. Some of it is your own preference, and changing it affects nobody else. Knowing which is which prevents both kinds of mistake: assuming a change will help your team when it will not, and worrying that a change will disturb them when it cannot.

Yours alone

Shared with everyone

• The screens themselves: which lists exist, their default columns, their default sorting, their buttons
• The record types and their fields
• The modules and the navigation structure
• Saved views that were published for everyone rather than kept private
• The application's language, which is set for the whole application and not per person
• The application's name, logo and colors

The browser-based items in the first table are worth reading twice. Because they live in the browser and not on your account, they do not follow you: sign in on a different computer, or in a private window, or after clearing your browsing data, and your theme, your column widths, and your pinned navigation all revert to their defaults. Your saved views and your dashboard do follow you, because those are stored on your account.

Example An analyst spends twenty minutes building a filtered view of unpaid invoices over 90 days, rearranging columns and widening the amount column. She saves the view. On her laptop at home the saved view is there and works immediately — but the column she widened is narrow again, because widths are a property of the browser she set them in, not of the view.

Nothing Updates By Itself

One habit is worth forming early: your screens do not refresh themselves.

A list shows the records as they were when the list was loaded. If a colleague creates an order while you have the order list open, it will not appear. If someone changes a status, your copy still shows the old one. This is deliberate — a list that reshuffled itself while you were reading it would be unusable — but it means a stale screen can be mistaken for current truth.

To pull current data, use the refresh control on the list, which re-runs the screen exactly as it stands: same filters, same sorting, same page. Reloading the whole browser page works too but throws away more of your context.

Two things do update on their own: your notifications, and the progress of background export jobs. Everything else waits to be asked.

There is one further consequence. If you and a colleague edit the same record at the same time, the last save wins, silently. Nobody is warned and no versions are merged. On records that several people touch, it is worth a quick word before a long edit. See Creating And Editing Records.

Words This Guide Uses

These are the terms the rest of the guide relies on. Your application may use different words on screen — that is expected, and it does not change what the thing is.

Three conventions are worth stating outright:

• Where this guide names a control in bold, the label is fixed by the platform and should match your screen (allowing for the application's language).
• Where a name appears in italics, it is an invented example of something your administrator would have named — a record type, a field, a button. Yours will read differently.
• Where this guide describes a control by position and icon instead of naming it, the label was chosen by your administrator and will differ in your application.

Where To Go Next

The guide is in six parts, listed with what each one covers in the guide index. You do not need to read them in order.

If you are entirely new, the fastest useful path is this chapter, then The Application Window, then List Screens, then Record Detail Screens. Everything else can wait until you need it.

Tips And Gotchas

• Absence is the normal signal. Missing rows, missing columns, missing buttons and missing menu entries are how the application expresses "not for you" or "not configured." Errors are rare; emptiness is common.
• An empty list is ambiguous. It may mean there are genuinely no matching records, that a filter you forgot about is still active, or that you may not read this type. If a filter is active, the empty list offers a button to remove your filters — use it first, then compare with a colleague, then ask.
• The names on your screen are local. Your administrator chose the record type names, the field captions, the tab titles and the button labels — and can change them. If a name in this guide does not match, the underlying thing is still the same.
• There is no undo, anywhere. No undo for an edit, an action, or a deletion. Deleting is permanent and immediate unless your administrator turned on keeping deleted records, which is a separate setting and not the default.
• There is no print support — no print layout and no print button. Export or take the data into another tool if you need it on paper.
• There is no spreadsheet import for end users. You can export to a spreadsheet, but bringing one back in is not something the application offers you. Bulk data loads are an administrator task.
• Pop-up windows do change the web address. While a record is open over a list, the address bar keeps the list's address and adds a marker for what is stacked on top, so that address reopens the list with the record over it. If you want a plain link to the record on its own, open it as a full page first and copy the address from there.
• If icons vanish or a date picker turns into a plain text box, your network is probably blocking part of what the application loads. It is not something you did. See When Something Goes Wrong.

What To Ask Your Administrator For

The things in this chapter are not settings you can change. These are, though — phrased as requests you can send:

• "Please add to the screen — I need it when I'm checking ."
• "The menu entry isn't visible to me. Could you check whether my role has access to it?"
• "Could and I be given the same role for ? We are seeing different rows and we cannot tell which of us is right."
• "Could the action get a confirmation step? It gets pressed by accident."
• "Could be added to the default columns of the list, so nobody has to add it each time?"
• "Could the list default to ?"

A fuller catalog of these is in What To Ask Your Administrator For.

Related Chapters

• Signing In
• The Application Window
• List Screens
• Record Detail Screens
• Why Your Screen Differs