• State Verified Answer
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 2 subscribers
  • Views 5 views
  • Users 0 members are here
Options
Related

Stop notifications for internal-only jobs?

Rachel Nguyen

We have a significant volume of internal work orders — equipment maintenance, warehouse moves, training sessions — that do not involve external customers. I have confirmed that these jobs are triggering the same automated SMS and email notifications as customer-facing work orders.

I can reproduce this when the Customer field is left blank or populated with an internal placeholder contact. The notification routing logic does not appear to distinguish between internal and external job types.

What I need to implement:

  1. Conditional suppression of customer-facing notifications when a work order is flagged as internal
  2. Alternatively, a notification template that routes only to internal staff

Current environment: FieldPulse web application v3.3.1, API v2.1. I have reviewed Setting Up Customer Notifications and found no explicit coverage of internal-only scenarios.

Is there a configuration toggle, custom field condition, or API-level control that would allow us to suppress customer notifications for designated internal job types? If not, what is the recommended workflow to prevent notification spam to placeholder contacts?

Parents
  • 0

    From a governance perspective, it is worth noting that suppressing notifications based on custom logic introduces audit considerations. I recommend implementing a consistent tagging scheme — we use INTERNAL-{dept}-{cost_center} — and documenting the notification suppression rationale in your change management log.

    It is also advisable to review whether placeholder contacts in your directory represent a data retention risk under your retention policy. If these 'customers' have no legitimate business relationship, they should be purged rather than maintained as active records.

    The API approach described above is sound, but ensure your webhook endpoint implements idempotency. We observed duplicate suppression calls during the 3.3.0 release window that created race conditions in notification state.

Reply
  • 0

    From a governance perspective, it is worth noting that suppressing notifications based on custom logic introduces audit considerations. I recommend implementing a consistent tagging scheme — we use INTERNAL-{dept}-{cost_center} — and documenting the notification suppression rationale in your change management log.

    It is also advisable to review whether placeholder contacts in your directory represent a data retention risk under your retention policy. If these 'customers' have no legitimate business relationship, they should be purged rather than maintained as active records.

    The API approach described above is sound, but ensure your webhook endpoint implements idempotency. We observed duplicate suppression calls during the 3.3.0 release window that created race conditions in notification state.

Children
No Data