Skip to main content
LendAPIField Guide

Appearance

Updated Oct 16, 2026

Application detail — Activity tab ​

The Activity tab is the audit timeline for one application: who did what, when the system ran automations, and how the application moved through steps. It is read-only — you do not send email or change status from here.

Select Activity as the last tab in the main tab bar.

[NEEDS SCREENSHOT: Activity tab with This week accordion expanded]

Layout ​

Events are grouped into collapsible accordions by time. On first load, all non-empty groups open automatically.

Group titleWhat it contains
This weekEvents since start of current week (Sunday-based)
This monthEarlier in the current calendar month
{Month name}Earlier in the current year (e.g. April)
{Month} {Year}Previous years (e.g. March 2025)

Click a group header to expand or collapse it.

If there is no history, the page shows: No application history.

Each timeline entry ​

Every line includes:

  1. Icon rail — dashed vertical connector between events
    • System (database icon) for automated events
    • User (person icon) for actions by a team member
  2. Header line — actor name (System or user display name), optional badge text from the event, and timestamp
  3. Description — plain language summary of the event

Event types and visuals ​

TypeWhat you see
updateDescription text; variable names with underscores may render as badges in the sentence
step_changePrevious step badge → arrow → new step badge (labels from your tenant’s step dictionary when available)
consentUnchecked box → checked box (consent captured)
viewHidden eye → visible eye (visibility change)
app_assignAssignment changes (in description)
document_status_updateDocument approved/rejected/requested (in description)

Other types fall back to description text only.

Step names ​

When tab_dict is configured for your tenant, step codes in step_change events show friendly labels (e.g. UNDERWRITING → Underwriting). Otherwise raw step codes appear.

Worked example ​

An underwriter opens application #48213, a $25,000 personal loan for an applicant in the 680–719 FICO band.

  1. The underwriter clicks the Activity tab.
  2. The page loads with skeleton blocks while history is fetched, then shows two open accordions: This week and June.
  3. In This week, the first entry shows the System icon, a step_change visual: a Submitted badge, an arrow, and an Underwriting badge, timestamped this morning. This tells the underwriter the application moved into underwriting automatically after submission.
  4. The next entry shows a document_status_update event with the User icon and the reviewer’s name — the description states a pay stub was approved.
  5. Below that, a consent entry shows a checked box next to the applicant’s e-sign consent, captured earlier in the week.
  6. In the June group (collapsed until clicked), an app_assign entry shows the application being reassigned from one underwriter to another.

The underwriter now has a full picture of how the file got to its current state without opening the Email or Notes tabs.

Use case ​

A credit union’s compliance team is preparing for an audit and needs to show exactly when an application’s consent was captured and when its status changed from Submitted to Underwriting. Instead of asking engineering to pull logs, the compliance reviewer opens the application, selects the Activity tab, and finds the consent entry (checked box, timestamped) and the step_change entry (Submitted → Underwriting badges) in the same timeline. Both entries show the timestamp and whether the change was made by System or a named user, which is what the auditor asks for.

What Activity is good for ​

  • Compliance and audits — prove when status, assignment, or consent changed
  • Debugging — see order of integration runs, doc reviews, and variable updates (alongside Integration and Data tabs)
  • Handoffs — new assignee reads Activity before calling the applicant
  • Customer calls — CSR confirms “when did we request documents?” without opening Email history

Activity does not replace Email history (delivery status) or Notes (internal-only commentary).

Best practices ​

  • Check Activity first when picking up a reassigned application — the app_assign entries and step_change history tell you how the file got to its current step before you call the applicant.
  • Use Activity, not Email, when you need proof of when a status or consent change happened. Email history tells you about delivery, not workflow state.
  • Collapse the right rail (Overview, SMS, Notes) before reviewing long descriptions — the Activity column gets a narrower width when the right rail is expanded, which can crowd out longer text.
  • Expand older accordion groups (This month, named months, or {Month} {Year}) rather than assuming all relevant history is in This week — older groups are collapsed by default but still contain the full audit trail.
  • Do not rely on Activity for internal commentary or reasoning about a decision — use Notes for that. Activity only shows what happened, not why a team member made a judgment call.

Loading state ​

While history loads, skeleton blocks approximate accordion sections.

When the right rail (Overview, SMS, Notes) is expanded, the Activity column may use a narrower width (~70% of content area). Collapse the right rail for a wider timeline when reviewing long descriptions.

LendAPI Field Guide.

Copyright © LendAPI