• State Verified Answer
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 2 subscribers
  • Views 11 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?

  • 0

    Hi Rachel, great question and thank you for the detailed reproduction steps. You're right that the current notification engine doesn't automatically distinguish internal vs. external jobs.

    Here is the recommended approach:

    1. Create a dedicated 'Internal' job type under Settings > Work Orders > Job Types
    2. Configure a separate notification template for this job type that excludes customer-facing channels
    3. Set the Notification Recipients to 'Assigned Technicians Only' rather than 'Customer + Technicians'

    For existing jobs, you can bulk update the job type via the API or reach out for assistance with a bulk edit.

    The placeholder contact approach you mentioned is actually a common anti-pattern — it can cause issues with reporting and sync integrations. I would recommend migrating away from that pattern if possible.

    Let me know if you need help with the API bulk update script.

  • 0

    We handle this via webhook + middleware. On work_order.created and work_order.updated, we inspect custom_fields['job_category']. If internal, we call PATCH /work_orders/{id} to set suppress_customer_notifications: true.

    curl -X PATCH api.fieldpulse.com/.../12345 \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"suppress_customer_notifications": true}'

    This prevents the notification from ever entering the queue. Requires webhook endpoint obviously.

  • 0 in reply to Carlos Vega

    Thank you for the technical detail. Can you confirm which OAuth scope is required for PATCH operations on work orders? I attempted with work_orders:read and received 403.

  • 0 in reply to Carlos Vega

    work_orders:write minimum. We use work_orders:admin for the service account.

  • 0

    Another approach that doesn't require dev work: we use Service Areas as a hack. Created a 'Internal' service area with no geofence, then disabled all customer notifications for that area in Notifications > Service Area Settings.

    Pro tip: You can also set the service area's default notification template to an internal-only version with your company branding but no customer variables. This keeps everything in-app configurable without API maintenance.

    Downside: technicians need to remember to select the right service area. We solved that with a required checklist question on job creation that routes to the correct area based on response.

  • 0 in reply to Gwen Albright

    Thanks so much for this! We have a similar setup and I was wondering if there's a way to automate the service area selection based on the customer field being blank? Right now our dispatchers have to remember to check and sometimes we still slip through!

  • 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.

  • 0

    Following up with a clarification: the suppress_customer_notifications field mentioned by Carlos is not officially documented in API v2.1. It exists in the underlying data model but has not been promoted to stable API surface.

    I have confirmed with engineering that using this field will not cause immediate breakage, but it is subject to change without deprecation notice in future releases.

    The officially supported method for notification control remains:

    1. Job type → notification template mapping
    2. Service area notification overrides
    3. Per-customer notification preferences

    For advanced use cases requiring runtime suppression, please open a support ticket to discuss your requirements — we are collecting feedback for a potential Notification Rules Engine feature in H2.

    See Configuring SMS and Email Alerts for documented template configuration.