<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>FieldPulse</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/</link><description>FieldPulse is a cloud-based operations platform designed for organizations that manage technicians, inspectors, installers, and other field-based workers. It enables teams to manage work orders, schedules, inventory, safety checklists, customer communicati</description><dc:language>en-US</dc:language><generator>14.0.0.622 14</generator><item><title>Forum Post: RE: Confirmed working: Offline status update sync resolved</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/user-q-a/248/confirmed-working-offline-status-update-sync-resolved/1401</link><pubDate>Thu, 23 Apr 2026 09:17:00 GMT</pubDate><guid isPermaLink="false">forumreply:1401</guid><dc:creator /><description>Hi Sam, happy to help confirm this! What you&amp;#39;re describing is exactly how offline status updates are designed to work. Here&amp;#39;s what&amp;#39;s happening under the hood: Status changes made offline are stored in a local queue On reconnect, the app syncs automatically (you&amp;#39;ll see the spinner Sam mentioned) Conflicts are resolved server-side with timestamps Important: Do not force-close the app while offline, as Art and Josh noted — this clears the queue. Backgrounding the app is fine. We&amp;#39;ve also seen improved reliability with this flow in app version 3.2.1 and later. If anyone is still experiencing issues after following these steps, feel free to tag me and I can dig into your specific account.</description></item><item><title>Forum Post: RE: Using Make (Integromat) instead of Zapier — gotchas?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/developer-integration-help/180/using-make-integromat-instead-of-zapier-gotchas/1014</link><pubDate>Thu, 25 Sep 2025 18:20:00 GMT</pubDate><guid isPermaLink="false">forumreply:1014</guid><dc:creator /><description>Perfect — the v1 vs v2 thing is exactly the kind of detail I needed. Already running into the &amp;quot;run it once to see data&amp;quot; pain, good to know that&amp;#39;s expected behavior and not me missing something. Will likely go HTTP module route for the newer endpoints. Appreciate the confirmation on OAuth refresh too.</description></item><item><title>Forum Post: RE: Using Make (Integromat) instead of Zapier — gotchas?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/developer-integration-help/180/using-make-integromat-instead-of-zapier-gotchas/1013</link><pubDate>Thu, 25 Sep 2025 16:45:00 GMT</pubDate><guid isPermaLink="false">forumreply:1013</guid><dc:creator /><description>Devon — yeah this one tripped me up too when I first looked at it. Leo&amp;#39;s right on the custom fields thing, that&amp;#39;s a platform limitation on our end not a Zapier/Make thing. The OAuth refresh is actually smoother in Make in my experience. Their &amp;quot;Connection&amp;quot; model handles token refresh automatically without the extra &amp;quot;Refresh Token&amp;quot; step you need in Zapier. Heads up though: if you&amp;#39;re using a custom OAuth app (not the default FieldPulse one in Make&amp;#39;s app directory), you&amp;#39;ll need to manually configure the token endpoint. That&amp;#39;s auth.fieldpulse.io/.../token with grant_type refresh_token . One gotcha that got me: Make&amp;#39;s &amp;quot;FieldPulse&amp;quot; app in the directory is on v1 of our API. If you need v2 features (like the new checklist endpoints), use the generic HTTP module and hit the endpoints directly. The v1 app works fine for work orders and customers, just not the newer stuff. Also worth noting — Make doesn&amp;#39;t have the same &amp;quot;Test Trigger&amp;quot; behavior as Zapier. You often need to run the scenario once to see sample data, which can be annoying when you&amp;#39;re building against production. I usually set up a filter early in the scenario to catch only test records while I&amp;#39;m building. Documentation link for the direct API approach: Using the FieldPulse API</description></item><item><title>Forum Post: RE: Using Make (Integromat) instead of Zapier — gotchas?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/developer-integration-help/180/using-make-integromat-instead-of-zapier-gotchas/1012</link><pubDate>Thu, 25 Sep 2025 14:12:00 GMT</pubDate><guid isPermaLink="false">forumreply:1012</guid><dc:creator /><description>Two things: Webhook payloads are identical — same JSON structure. The difference is Make parses nested objects differently in the trigger data mapper. Check the &amp;quot;Data structure&amp;quot; settings on your webhook module. Custom fields: same limitation as Zapier. The custom_fields array is not expanded in trigger payloads. You need a second API call to /work_orders/{id} with include=custom_fields . See Setting Up Webhooks — the payload examples there apply to both platforms.</description></item><item><title>Forum Post: RE: Limiting technician view/edit permissions — how granular?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/user-q-a/199/limiting-technician-view-edit-permissions-how-granular/1121</link><pubDate>Tue, 26 Aug 2025 12:10:00 GMT</pubDate><guid isPermaLink="false">forumreply:1121</guid><dc:creator /><description>Anita — thank you for that detailed follow-up. I have reproduced the search behavior you described and confirmed this is unintended. Customer records from unassigned jobs should not surface in mobile search when the restriction is enabled. I am escalating this to our engineering team as a bug. You should receive a ticket reference within 30 minutes. The workaround until resolved: disable search for technician role users (toggle under Mobile Permissions ), though I recognize this impacts usability. Your documentation of this as a control deficiency is appropriate. I will update here when the fix is scheduled.</description></item><item><title>Forum Post: RE: Limiting technician view/edit permissions — how granular?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/user-q-a/199/limiting-technician-view-edit-permissions-how-granular/1120</link><pubDate>Tue, 26 Aug 2025 09:47:00 GMT</pubDate><guid isPermaLink="false">forumreply:1120</guid><dc:creator /><description>Thank you for the responses. I have implemented the &amp;quot;Restrict to assigned work orders only&amp;quot; setting as described. I can confirm that technicians with this restriction enabled are unable to view unassigned jobs in both the web interface and mobile application. This satisfies requirement #1. However, I have identified an inconsistency: when a technician uses the search function in the mobile app, customer records from unassigned jobs appear in search results with partial address information. This occurs despite the restriction setting. I have documented this behavior with screenshots and will submit a support ticket unless this is a known configuration issue. Regarding the pricing visibility gap: I have logged this as a control deficiency per Fatima&amp;#39;s recommendation. We will proceed with the $0.00 template approach as an interim compensating control, with manual dispatcher review of all closed work orders. Please confirm whether the search visibility behavior is expected or requires escalation.</description></item><item><title>Forum Post: RE: Limiting technician view/edit permissions — how granular?</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/user-q-a/199/limiting-technician-view-edit-permissions-how-granular/1119</link><pubDate>Tue, 26 Aug 2025 08:15:00 GMT</pubDate><guid isPermaLink="false">forumreply:1119</guid><dc:creator /><description>It is worth noting that the pricing visibility limitation Priya identified may have compliance implications depending on your jurisdiction and contractual obligations. From a governance perspective, I would recommend documenting this as a known control gap in your internal risk register. Anita, you may wish to reference Managing User Roles and Permissions for the current permission matrix, though I have confirmed the documentation does not address field-level granularity beyond what Priya outlined. Additionally, it is worth noting that API access (if provisioned for your account) inherits the requesting user&amp;#39;s role permissions. If you are considering custom integrations to enforce pricing restrictions at the data layer, ensure your API keys are scoped appropriately and audit access quarterly.</description></item><item><title>Forum Post: RE: Build custom mobile interface using FieldPulse API</title><link>https://verint14-pre-02.socialedgeconsulting.io/product-fieldpulse/f/developer-integration-help/185/build-custom-mobile-interface-using-fieldpulse-api/1040</link><pubDate>Sun, 27 Jul 2025 09:15:00 GMT</pubDate><guid isPermaLink="false">forumreply:1040</guid><dc:creator /><description>Can you share the actual error on session handling? Specific flow and IdP would help. Also — what does your /work_orders response payload look like for a record with checklist data? Want to confirm you&amp;#39;re expanding the right nested fields.</description></item></channel></rss>