Purpose of notification sending records

Notification sending records help confirm who received a notification, what content was sent, which channel was used, when it was sent, whether sending succeeded, whether a third-party service accepted the message, whether sending failed, and why it failed.

These records help institutions understand the actual execution status of notification tasks.

Supported notification types

Depending on enabled features, sending records can cover in-app notifications, App Push, Apple APNs, Google FCM, SMS, Email, system messages, targeted-user notifications, user-group notifications, scheduled notifications, business-triggered notifications, and other custom messages.

The exact channels that can be recorded depend on the institution's current configuration and enabled notification services.

Recorded information

A notification sending record can include sending time, Notification ID, Organization ID, notification type, sending channel, recipient, User ID, user group, notification title, content summary, sending status, third-party service status, Message ID, Error Code, Error Message, retry count, creator, and other related information.

For batch sending tasks, the system can show both overall task status and per-user sending results.

Sending status

Notification records can include states such as Pending, Processing, Sent, Delivered, Failed, Rejected, Expired, and Cancelled.

Different channels may provide different delivery states.

For example, some third-party services can only confirm that a message was submitted successfully, but cannot guarantee that the device received it or that the user viewed it. Therefore, sending success and user read status should be treated as separate concepts.

Push sending records

For App Push, the system can record push requests sent through Apple APNs or Google FCM.

For example: Channel = Push, Provider = Apple APNs, User = User 10284, Status = Sent, Message ID = push_8F291C.

If sending fails, the system can record causes such as Invalid Device Token, Device Token Expired, Provider Authentication Failed, or Push Service Unavailable. These records help technical teams identify why Push cannot be delivered.

SMS sending records

If the institution enables SMS service, SMS sending status can be viewed in sending records.

For example: Channel = SMS, Recipient = +81******1234, Provider = the institution-configured SMS provider, Status = Delivered.

Records can be generated for both Finger Manager hosted SMS service and institution-owned SMS provider accounts, depending on the actual integration.

Email sending records

Email notification records can include recipient, email subject, sending time, SMTP or email provider, sending result, Message ID, and failure reason.

If the institution has configured its own SMTP or email provider account, related messages are sent through the configured channel.

Batch notifications

For user-group or batch notifications, records can show overall execution status.

For example: Target Users = 10,000, Sent = 9,832, Failed = 168, Processing = 0.

Administrators can further inspect failed users and failure reasons. This is suitable for campaign notifications, system announcements, market notices, user-group operations, batch risk alerts, and similar scenarios.

Scheduled notifications

If a message is sent through a scheduled task, sending records can retain scheduled sending time, actual sending time, creator, execution status, and sending result.

For example: Scheduled Time = 2026-08-29 09:00, Actual Send Time = 2026-08-29 09:00:03, Status = Completed.

This helps institutions confirm whether scheduled tasks executed as planned.

Failure troubleshooting

When notification sending fails, teams can first check whether user contact information is valid, Device Token is valid, Apple or Google push credentials are correct, SMTP settings are correct, the SMS provider account is normal, third-party service balance or quota is sufficient, API Key is valid, message content follows provider rules, third-party services are healthy, and network connectivity is normal.

Error Code and Error Message in notification sending records are important evidence for troubleshooting.

Record query

Institutions can query sending records by time range, User ID, Notification ID, notification channel, sending status, user group, creator, Message ID, and Error Code.

For example, administrators can query all failed Push sending records in the past 24 hours, or all system notifications received by a specific user in the past 30 days.

Relationship with notification features

The notification module is used to create and send notifications. Notification sending records are used to review how those notifications were actually executed.

For example: create notification -> select user group -> select Push + Email -> system starts sending -> sending records are generated -> administrators review sending results by channel and user.

This forms a complete notification management workflow.

Third-party sending services

Some notifications rely on third-party services for actual delivery, such as Apple APNs, Google FCM, SMS providers, email providers, institution-owned SMTP, or institution-owned third-party messaging services.

Finger Manager can record message submission and returned results from these services.

Final delivery status can still be affected by user device status, network status, third-party service rules, mail servers, mobile carriers, and user system settings.

Example

For example, an institution sends a system maintenance notice to 5,000 users.

Notification Name = System Maintenance Notice; Channels = Push + Email; Target Users = 5,000; Push = 4,891 Sent and 109 Failed; Email = 4,972 Sent and 28 Failed.

Administrators can continue to inspect failed records and confirm the specific users and error reasons.

Notes

Notification sending records are mainly used to track execution status for message tasks in Finger Manager.

Institutions can use sending records to understand channel operating status and troubleshoot based on third-party service return results.

The status shown in sending records should be interpreted according to the receipt capability of each notification channel.