Availability requests and attendance regularization

An Availability Request is a request that a field user raises on the mobile app and that someone else approves or declines. Three mobile screens create one: Regularize on the attendance calendar (correct a day's check-in and check-out), Outlet Transfer (move outlets to another beat) and Visit Route Regularization (change a beat's schedule). Raising a request never changes anything by itself. The change, if any, happens only when the request is approved.

Overview

The record that xMatix delivers is deliberately thin. It has only three fields of its own: Request Name, Request Type and Status. Everything a particular kind of request needs, such as the day being corrected, the punch times, the beats or the requester, is a custom field that your administrator adds to the entity. The mobile screens are told those field names in the mobile designer.

Request Type tells the three kinds apart. Each screen stamps its own value on the requests it creates and lists only requests of that value:

These are the default values. An administrator can change each one in the screen's settings.

This page covers the request record and the attendance regularization flow in full. The outlet and beat flows are described step by step in Route stops and Beats and routes.

When to use it

• Regularize a day when your attendance shows the wrong check-in or check-out, for example because you forgot to punch in or your phone was off.
• Use Outlet Transfer when outlets belong on a different beat of the same channel partner.
• Use Visit Route Regularization when a beat should run on different weeks or days.

Don't edit an Availability Request on the web to "approve" an attendance correction. The approval process, not a typed Status, is what puts a request in front of the approver and records the decision.

How xMatix handles it

• Self-scoped calendar. The attendance calendar always shows the signed-in user's own attendance, resolved from the Resource linked to your user account. Opening a colleague's Resource record still shows your own calendar. If your user has no linked Resource, the calendar says so instead of showing an empty grid.
• One live request per date. You can't raise a second attendance request for a date that already has one, unless the earlier request was Rejected (or cancelled). A rejected day stays open so you can try again. The app checks this against your requests of the same Request Type, which it reads only while you're online. A request submitted offline isn't checked against earlier ones.
• Correction window. Only days from today back to the correction window (30 days unless your administrator changed it) can be regularized. Future days can't be regularized.
• Same-day punches. Check-Out must be later than Check-In, and both are stored on the selected date, so a pair can't run past midnight.
• Works offline. If you submit while offline, the request is saved on the phone and sent when you're back online. The My Requests list itself needs a connection.
• Sent for approval on submit. When you're online, the app saves the request and then submits it to the entity's approval process, if one applies. A request saved offline is submitted only if the approval process submits automatically on create.
• Nothing is rewritten for attendance. Approving an attendance request does not change the Resource Availability day or its punches. What approval changes is decided entirely by the approval process your administrator configures.

Prerequisites

• Your user account is linked to a Resource. The calendar resolves your Resource from your user.
• Your administrator has added the Availability Calendar (shown with the title Resource Availability by default) to a mobile page or layout, with Show regularization on.
• Your administrator has added the custom fields the form uses to the Availability Request entity. See Configuration.
• For approval: an active approval process on Availability Request, and an approver who is set up as a user.

Procedure

Step 1 — Open your attendance calendar

On the mobile app, open the page where your administrator placed the attendance calendar. The card shows My availability and a count of the records on screen. Switch between Month, Week and Day with the View pill if more than one view is offered, and use the arrows to move between months.

Step 2 — Start a regularization

Select Regularize. Alternatively, tap a day in the grid. A tap opens the form with that date filled in. Days outside the correction window, and future days, do nothing when tapped.

Step 3 — Fill in the request

The default form asks for:

• Date: the day you are correcting. It is always asked.
• Check-In Time and Check-Out Time: the times the day should have had.
• Reason: why the day needs correcting.

Your administrator can remove Check-In, Check-Out or Reason, or add other fields to the form. Any field that the entity marks as required must be filled.

Step 4 — Submit

Select Submit. The app checks the form first and shows the first problem it finds (see Common problems). When the form passes:

• online, with an approval process that applies: you see "Regularization request sent for approval.";
• online, with no approval process that applies: you see "Regularization request saved." The request exists but no one has been asked to approve it;
• offline: you see "Request saved — it will sync when you are back online."

The new request's Status is Draft unless your administrator set a different starting status.

Step 5 — Follow your requests

Select My Requests. A card at the top shows your name, your employee code and your approver (your Resource's Manager). Below it, filter by All, Draft, Approved or Rejected. Each date appears once. If you raised a new request after a rejection, the newest request for that date is shown.

Step 6 — Approve or reject (managers)

Where your administrator has added an Approvals inbox to a page, it lists the requests waiting for you, with the fields the administrator chose (for example Date, Check-In Time, Check-Out Time and Reason). Select Approve, or Reject and enter a reason. Without the inbox, act on the request from its approval panel. See Approvals on mobile.

Outlet Transfer and Visit Route Regularization requests are decided on their own screens, not in the approvals inbox.

Fields

The fields delivered with the entity:

The fields the attendance calendar expects, all of which your administrator adds as custom fields:

Business rules

• A request is accepted only for a date from today back to the correction window.
• Only one request per date counts, unless the earlier one has a Status containing "Rejected" or "cancel".
• Check-Out must be later than Check-In, and the pair can't cross midnight.
• The calendar fills in Request Name, Resource, Request Type and Status itself. These fields can't be added to the form.
• A blank Status reads as Draft in My Requests.
• Outlet Transfer and Visit Route Regularization requests are routed to the requester's manager (the Manager on the requester's Resource). The Approvals sheet on those screens appears only for people who have someone reporting to them. The manager's Approve does the change first and sets Status to Approved only if the change succeeds. A decline sets Status to Rejected and writes the reason to the request's Reason field.

Example

An executive forgot to check in on 5 October and only the check-out was recorded. On 7 October they open the attendance calendar, tap 5 October and enter Check-In Time 09:15, Check-Out Time 18:30 and Reason "Phone switched off at start of day". They select Submit and see "Regularization request sent for approval." In My Requests, 5 October shows as Draft.

Their manager opens the Approvals inbox, sees the request with its date, times and reason, and selects Approve. The approval process sets Status to Approved, which the executive's list now shows. The payroll administrator then corrects the 5 October attendance day, because approval doesn't change the attendance record.

Training

Practice exercise

In a sandbox where the calendar and custom fields are set up, sign in as a field user who is linked to a Resource:

1. Open the attendance calendar and tap a day from last week.
2. Enter a reason and a Check-Out time earlier than the Check-In time, then submit. Expected: "Check-Out time cannot be earlier than or equal to Check-In time."
3. Correct the times, enter a reason and submit. Expected: the request appears in My Requests as Draft.
4. Tap the same day again and submit another request. Expected: "You have already submitted a request for this date."
5. Tap tomorrow. Expected: nothing opens.

Quick reference

• Regularize corrects one day. Tap the day or select Regularize.
• One live request per date. A rejected day can be raised again.
• Only the correction window (30 days by default) is accepted, never the future.
• Check-Out after Check-In, same day.
• Offline submissions are saved on the phone and sent later.
• My Requests needs a connection.
• Approval doesn't change the attendance day.

Permissions

Profiles control access to Availability Request in the usual way. In the delivered profiles, Sales, Sales Executive, Sales Manager, Service, Standard User and System Admin have full access to the entity. Its record sharing is delivered as Read Only for internal users, so everyone with read access sees every request. Changing a request someone else owns needs ownership, the role hierarchy or Modify All. See Security scenarios.

A manager who approves an Outlet Transfer or Visit Route Regularization updates a request that the team member owns, so the manager needs edit access to it. For outlet transfers, the manager also needs the Transfer Stops grant described in Route stops.

Configuration

Add the custom fields

Go to Setup → Design Studio → Entities → Availability Request → Schema → Fields and add the fields each screen needs (see Create an entity for how fields work). For attendance, the calendar's default field names are Date_c, CheckInTime_c, CheckOutTime_c, Reason_c and ResourceId. Name your fields to match, or change the names in the calendar's settings. Make Check-In and Check-Out time fields, not date-time fields. A value the field can't read as a time is stored as empty, with no error.

For the field names used by Outlet Transfer and Visit Route Regularization, see each screen's settings in the mobile designer.

Add picklist values

Request Type and Status are delivered with no values. Add the values your screens write (for example Attendance, Outlet Transfer, Visit Regularization; Draft, Approved, Rejected) so that people working with requests on the web can pick them.

Set up the approval process for attendance

Create an approval process on Availability Request under Setup → Process Studio → Approvals (see Approval processes). Give it an entry condition on Request Type so that it claims only attendance requests. Make sure its approver step resolves to a user. Add final field updates that set Status to Approved on approval and Rejected on rejection. Without them, My Requests keeps showing Draft, and a rejected day stays blocked. To have requests saved offline reach the approver, turn on auto-submit on create.

Place the calendar

Add the Availability Calendar to a mobile page (for example through Setup → Design Studio → App Pages, in the page's mobile design). Its settings:

Place the approvals inbox

Add the Approvals inbox to a manager's mobile page. Set Entity to Availability Request and, optionally, Approval process to the process's label. Choose Card fields (for example Date, Check-In Time, Check-Out Time, Reason). Reason required to reject is on by default. Its Transfer tabs (Outlet Transfer, Visit Transfer) show no requests, so turn them off. Managers decide those requests on their own screens.

Make records reachable on the web

Availability Request isn't in any delivered app. To list requests on the web, add the entity to an app under Setup → Design Studio → Apps → Manage Items.

Common problems

"Please fill the following field(s): …"

A field on the form is empty. Fill the fields named in the message.

"A future date cannot be regularized."

You picked a day after today. Choose today or an earlier day.

"Only the last 30 days can be regularized."

The day is outside the correction window. Ask your administrator if older days need correcting. The number in the message is your configured window.

"You have already submitted a request for this date."

A Draft or Approved request already exists for that date. Check it in My Requests. You can raise a new request only after the earlier one is rejected.

"Check-Out time cannot be earlier than or equal to Check-In time." or "Check-Out time cannot cross midnight."

Correct the times so that check-out is after check-in on the same day.

"Request saved, but it could not be sent for approval"

The request was saved but submitting it to the approval process failed. The message gives the reason. Ask your administrator to check the approval process, then submit the request from its approval panel.

"Regularization request saved." but nobody received it

No active approval process applies to the request, so it was saved without being sent to anyone. Your administrator needs to create or activate one.

My Requests is empty or shows an error

My Requests needs a connection. If you're online and the error persists, the field names in the calendar's settings probably don't match the entity's fields. Your administrator should compare them.

An approved request still shows Draft

The approval process doesn't update Status. Your administrator should add final field updates for approval and rejection.

My times disappeared from the request

The check-in or check-out field is not a time field, so the value was stored as empty. Your administrator should check the field types.

Common questions

Does approving a regularization fix my attendance?

Not by itself. Approval records the decision on the request and applies any field updates in the approval process. Those updates act on the request, not on your attendance day. Your Resource Availability day and its punches stay as they were, so whoever manages attendance corrects the day separately. Ask your administrator how this is handled in your organization.

Who approves my request?

For attendance, the approver comes from the approval process your administrator set up. My Requests shows your Resource's Manager as your approver. For outlet transfers and beat schedule changes, your Resource's Manager decides on the same screen. If no Manager is set on your Resource, nobody sees those requests.

Can I raise a request for someone else?

No. The calendar always works on your own attendance, resolved from your user account. A manager can't raise a regularization on a team member's behalf from the calendar.

Can I cancel a request?

The mobile screens have no cancel button. A request can be deleted from the web by someone with access. Approval processes that allow recall let the submitter recall a pending request from its approval panel.

Related topics

• Mobile attendance
• Route stops (Outlet Transfer)
• Beats and routes (Visit Route Regularization)
• Approvals on mobile
• Approval processes
• Availability Request reference