Super Admin Dashboard - Issue reports

Kate Santo Updated by Kate Santo

The Super Admin Dashboard is closely linked to forms. Forms allow admins to collect information from members. A good example is issue reporting: for property apps, when a tenant has an issue on their flat, they can report it through the app. Those reports are collected through a form and then added to the Dashboard.

Read more about forms in our guide: Create and Manage Forms (Information Collection).

Although there are other tabs within the Super Admin page, this guide is about the first tab: the Dashboard. You can also view the user version of this guide here.

See for yourself

  • The Super Admin dashboard is currently only accessible via the web app. Log in or sing up to the web app here
  • On the web version of the app, head to Manage and then Super Admin at the top. Select a group you're an admin for. This will take you to the Super Admin space, where you'll see the tab called Dashboard
  • You can also follow along by checking out the images or code snippets in this guide
  • And you will find the relevant endpoints linked and explained in this guide, but the full API is documented in Swagger UI

Prerequisites

  • For forms to display in the UI, the padoq needs its official and qrCodesEnabled parameters setting to true. This can only be done by an admin at Padoq (i.e. padoqs are not official by default)

The Dashboard

The Super Admin dashboard is made up of 3 components: overview, filters and report. Here's an example of what it looks like.

Overview

The overview part at the top contains 4 key metrics that help the user understand the status of their padoq at a glance:

  • Total overdue tickets: When issues are reported (by posting a form response), they come with an effectiveTimestamp and they are placed in a pre-defined workflow (these are both properties within the post payload). The workflow property defines SLAs (service level agreements) to resolve each type of issue reported. The app can identify and count overdue posts by comparing the time passed since when they were posted with the established SLA
  • Number of reported posts: When the dashboard launches, the getPosts endpoint is called. Each post of type form and form_rs is retrieved. There's a property in each post's payload called action. All posts with an action type of report are counted and added up to this field here. Posts are reported through the reportPost endpoint. The admin can choose to accept the report and delete the post, or they might choose to reject the report, keep the post active and delete the post report instead
  • Number of new tickets this week: This is a simple calculation based on the effectiveTimestamp for each post
  • Number of members: This a count of how many personas are members of the padoq. The number is retrieved via the getUserPadoqs endpoint, which returns a payload with a property called memberCount

Filters

In a standard desktop view, there are 2 rows that hold fields, filters and buttons.

  • There is a search field where the user can type keywords and find all issues that have that word in common. The search is performed in the description and category columns of the report
  • There is a status toggle that allows users to only see open or closed issues. This toggle uses the status property in a post payload. Read more about post status in our Post types guide
  • There are 3 buttons that allow admins to create, delete or export issues
    • Issues are created via the createPost endpoint. Instead of a member of the padoq reporting an issue, the admin can create an issue from the dashboard. This is useful if a tenant has reported something verbally or in an email, for example. The admin can then input the details and manage the issue from the same workspace
    • The delete button only becomes active when an issue is selected
    • The export button downloads a csv file to the user's device with details of all issues visible in the report when the button is clicked (i.e. if there are filters applied, the csv downloaded will reflect that)
  • There is a date filter that allows users to filter issues reported by year and month. This uses the effectiveTimestamp property in a post payload

Reports

The final part of the Super Admin Dashboard is the report. This is where all issues are presented in rows. The filters we've just mentioned modify the list of issues in this section. There are 8 columns in the report, plus an option to view or export each issue individually.

The majority of columns (except for Created by, Description and Closed date) are clickable and they change how the rows are ordered. So users can see reports in a way that's more relevant to them (i.e. they can order by time left to prioritise issues that need resolving faster).

Here's what's in each column.

  • Created by: In a form_rs post, there are authorId and authorDisplayName properties. These specify the identity of the user reporting an issue, and they are used to populate this first column in the report
  • Assignee: For each issue reported, an admin can assign it to another admin (or to themselves). The assignee property lives in the FormPostWorkflow schema (check out the JSON for that schema)
  • Description: This is defined when an item is created in a padoq. When a user selects an item in the UI, the description linked to that item (inventory) appears in the report. The information is stored in the description property in the Inventory schema, fetched via the getInventories endpoint
  • Category: Similarly to descriptions above, categories in this report are taken from the category linked to the item (inventory) the user selected for their issue. They live in the same schema, but under the category property
  • Status: These are part of the workflow associated to all form and form_rs posts. The admin can update the status from the UI. When they do, the updateWorkflow endpoint is called. The request body contains only 1 property, state, which carries 1 of the 5 possible values: IN_PROGRESS, DEALING_WITH, THIRD_PARTY_SOURCED, CLOSED
  • Date created: When a user creates an issue via the createPost endpoint, the payload comes with an effectiveTimestamp property. The value of that property populates this column
  • Closed date: This is the timestamp recorded when an admin updates the status of an issue as CLOSED
  • Time left: When issues are reported (by posting a form response), they come with an effectiveTimestamp and they are placed in a pre-defined workflow (these are both properties within the post payload). The workflow property defines SLAs (service level agreements) to resolve each type of issue reported. The app calculates the time left to resolve an issue by comparing the time passed since when it was posted with the established SLA
  • View / Export: These are two buttons placed at the end of each issue row. View opens the issue and brings up its details. This is where admins can update status, message the user who created the issue and assign the issue to an admin. When a message is added, the admin can choose whether it's an internal message or a message to the user who reported the issue. This is reflected in the recipientRoles property of the post_rs payload: if the message is internal, recipientRoles will have a value of admin. If it's for the user, it will have a value of member. Finally, Export downloads a csv file to the user's device with the issue's details

How did we do?

Notifications and activity

Create and Manage Forms (Information Collection)

Contact