Explore

Event Log

What this is:

At some point, you’ll want a record of what’s happened in your app. Event Logs give you rich information of what users are doing.

How I do it:

Create an “Event Log” data type, w/these fields:

Field Name

Field Type

DT/OS

Notes

Type

(see examples below)

Date

User Taking Action

Related [Data Type]

You’d add field for any potential data type you might be collecting event logs for.

Notes

To include additional information about that event. Example: If a project’s status was changed, this note might be: “Old Status = Draft, New Status = Published”

From App Location

This tells us where the user took this action. (see

Pages, Views, Menus

⁠

for more info)

No results from filter

⁠

Examples of “Related [Data Type]” fields:

You will probably end up with many of these fields on the “Event Log” data type. The purpose is to tie the event to whatever that event was about. A few examples from apps I’ve built:

Related User - Let’s say you want to track when one user likes or blocks another user. You’d put that second user in this field.

Related Invitation - When a user signs up from an

Invitations⁠

record, you’d put that invitation in this field.

Related Project - When a user changes the status of a project, that Project goes in this field.

Related Relationship - When any pertinent field (Status, Permission Level) is changed in a relationship, that relationship goes in this field.

Some nice side benefits of this setup:

Having records that log this kind of information means you don’t have to save things like “Date Closed” or “Date Sent” (etc.) directly on the data type.

You can show users a list of activity related to a particular record.

Notes:

Workload Units: If there’s a lot of activity in your app, this could add up in terms of WUs. In that case, you would probably want some other activity logging system (an API call to create a record or event in an external database, for example).

Logic: The workflow to create events would live in the backend so it can be easily accessed from anywhere in the app.

Redundancies: It’s true that a record simply existing (let’s take a Project as an example) means the creation of that project happened. You don’t really need a “Project Created” Event record to tell you that. You can just look at the database for projects and see how many there are, when they were created… However in the early days of an app, I typically do create these events for these reasons:

To have all of your events in one data type, and view them in the same table or graph.

To easily migrate that data to some other data source once your app grows.

To be able to see a history of a thing in a single list (i.e. “Project history” repeating group).

Example Event Types

Display

Related To...

Notes

Invitation Created

Invitation Sent

User Signed Up from Invitation

Permission Level Change

Note would indicate the “from” and “to” status

[Thing] Viewed

[Thing] is a placeholder for any data type you’d want to track views for.

[Thing] Created

[Thing] Status Changed

User logs in

User visits [x] app location

No results from filter

⁠

Notes:

Generic Event Types: In order for this to be useful at all, you need to create separate event types for any important action you want to track. An single event type called “Project Created/Updated/Deleted” is useless - it covers way too much.

[Thing] Updated: A “[Thing] Updated” event type is also pretty useless. If you want to track activity on a thing you probably want to know more about it. For example, I tend to create event types like this:

[Thing’s] Status Changed

[Thing’s] Owner Changed

[Thing’s] Visibility Changed

When to do this: It’s important to map out the types of “reports” you’d want to be able to view in your app as early as possible so that you have robust historical data. Even if you don’t actually build the reports UI yet, you’ll have the data when you’re ready.

Ongoing maintenance: As you continue to build new features in your app, you need some way to remind yourself to capture any new events that should be captured. This is especially true if you hire someone else to build those features. They need to know that this data needs to be captured, and to include loggin as one of their development tasks.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.