https://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/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 communicatien-US14.0.0.622 14https://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/f/user-q-a/248/confirmed-working-offline-status-update-sync-resolved/1535Thu, 09 Jul 2026 18:43:00 GMTforumreply:1535Thanks for sharing this. For FieldPulse, I would first confirm that the mobile app has synced recently, then compare the work order status in the technician view with what dispatch sees. If those match, capturing the job number and last sync time will make it easier for support to trace the update.https://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK161/workaround-api-pagination-for-large-data-exportsWed, 06 May 2026 06:58:00 GMTarticle:c6360da0-13d0-4aa5-89a4-a0be55695340Yeah this one tripped me up too when I first looked at it. You're hitting 429s halfway through a big export and losing data, which is... not ideal. The API's pagination at the time of writing has this quirk where the offset parameter interacts badly with rate limiting if you're moving through large datasets quickly. What you're seeing Your export script runs fine for a few hundred records, then starts getting 429 responses. You back off, retry, but now your offset math is off because some pages returned partial data before the rate limit kicked in. Been there. The workaround: cursor-based pagination with a local checkpoint Instead of trusting offset and limit alone, use the created_at or id field as a cursor. This one's idempotent — if you hit a 429, you can retry the same cursor without drifting. GET /v2/work-orders?created_after={cursor}&limit=100&sort=created_at:asc Store the last id or created_at you successfully processed. If the request fails, retry with exponential backoff starting at 2s. The key is never advancing your cursor until you've confirmed the page is fully written to your destination. Sample flow (pseudocode, but you get it) cursor = "2024-01-01T00:00:00Z" while True: try: page = fetch(f"/work-orders?created_after={cursor}&limit=100") if not page.items: break write_to_destination(page.items) cursor = page.items[-1].created_at # last item becomes next cursor except RateLimit: sleep(backoff) backoff *= 2 # yeah this can get long, but it works Edge case worth mentioning: if you have multiple records with the same created_at at a page boundary, you might get duplicates. I usually dedupe on id at the destination, or switch to id cursor if your data has tight timestamps. The catch This is slower than raw offset pagination. You're looking at maybe 2-3x the wall time for a full export. But it's the only reliable way I've found to get complete data when you're in the 10k+ record range. Related: if you're hitting this because you're trying to build a data warehouse sync, heads up that webhook delivery is generally more reliable for that use case. See this thread on warehouse exports for a different approach. Also worth noting: the engineering team's aware of the offset+rate-limit interaction. No ETA on a proper fix, hence this workaround.workaroundpaginationapirate-limitexporthttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK158/workaround-manual-sync-for-stale-mobile-dataWed, 06 May 2026 06:57:00 GMTarticle:74ac47f5-992f-4a10-8018-26858788c4b4Hi there! Happy to help with this workaround for when your mobile app isn't showing the latest work order data. Summary: Force a manual sync when automatic background sync fails to refresh your work order list. Symptoms Work orders you've completed still showing as "In Progress" New assignments from dispatch not appearing in your list Changes made by other technicians not visible Last sync timestamp shows hours ago despite active connection Resolution Steps Open the FieldPulse mobile app and navigate to your Work Orders list Pull down on the list with your finger to trigger the refresh gesture (you'll see a spinning indicator) Hold for 3–5 seconds until the "Syncing..." banner appears at the top Wait for the sync to complete — do not close the app or switch apps during this time Verify the Last updated timestamp has refreshed If Pull-to-Refresh Doesn't Work Tap your Profile icon (bottom right) Select Settings → Sync & Data Tap Force Full Sync Confirm when prompted — this may take 1–2 minutes for large datasets Important Notes This workaround addresses the sync gap but doesn't prevent it from recurring. The engineering team is investigating root causes in versions 3.2.0–3.2.3. We'll update this article when a permanent fix is released. If you find yourself needing this workaround more than twice daily, please check our discussion on mobile app consistency or reach out to support with your device details.workaroundmanualsyncmobilehttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK159/workaround-compressed-photo-upload-for-slow-connectionsWed, 06 May 2026 06:57:00 GMTarticle:7833ed27-2169-44d0-8529-c879f66791fbBeen running into this one on rural job sites where cell coverage is spotty at best. When you're trying to upload photos from a completed job and the progress bar just sits there spinning, this workaround's saved me more than a few times. Summary: Manually compress photos on your device before uploading to FieldPulse when you're on a weak or metered connection. Symptoms you'll see: - Photo upload stuck at 0% or timing out repeatedly - "Upload failed" errors after multiple retries - App draining battery trying to retry failed uploads - Other sync tasks blocked behind photo uploads Why this happens: FieldPulse mobile captures full-resolution images (which is usually what you want for documentation), but on 2-3 bar LTE or flaky site WiFi, a 4-6MB photo times out before it completes. The app doesn't auto-compress — it just keeps retrying the same large file. Workaround: 1. Before you start your jobs for the day, open your phone's camera settings and temporarily switch to a lower resolution or "medium quality" mode. On iPhone: Settings > Camera > Formats > High Efficiency (already default) but also check that you're not in ProRAW. On Android: Camera app > Settings > Photo quality > Medium. 2. Pro tip: If you've already taken high-res photos and need to get them uploaded now, use your phone's built-in image editor to crop slightly (even 10% off edges) — most phones save the edited version as a new compressed file. 3. For iOS: Open photo > Edit > Crop > adjust slightly > Save as New Photo. Upload that version. 4. For Android: Gallery > Edit > Crop > Save Copy. The copy is usually 30-50% smaller. 5. Alternative if you've got tons of photos: Use a compression app like Image Size (iOS) or Photo & Picture Resizer (Android) to batch-shrink images to ~1200px width before upload. Still plenty clear for documentation purposes. Important caveats: This is a workaround, not a fix. You're trading image quality for upload reliability. If you need original resolution for insurance claims or warranty documentation, mark those specific photos and re-upload later on WiFi. Don't use this for photo evidence you might need to zoom way into later. What FieldPulse says: This is a known limitation — see Photos Upload Slowly on Weak or Spotty Connections for the official issue. Engineering has discussed auto-compression but it's not on the near-term roadmap from what I can tell. If anyone's found a better workflow for this, especially on Android, I'm all ears. The built-in editors vary a lot by manufacturer.workaroundphotoscompressionuploadhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK160/workaround-browser-refresh-for-missing-dispatch-jobsWed, 06 May 2026 06:57:00 GMTarticle:35f1c74f-ceae-4113-8953-82b3ea0b8842Summary: Hard browser refresh restores missing jobs when client-side filtering causes display issues. We've been running into this one pretty regularly in our ops, and while it's not a permanent fix, it's saved us from a lot of unnecessary panic. Here's what we're doing when jobs vanish from the dispatch board. Symptoms Jobs you know exist aren't showing on the dispatch board Refreshing the page with F5 doesn't bring them back The job count badge shows a different number than visible cards Filter pills appear empty or show "0 selected" when they shouldn't Cause The dispatch board uses aggressive client-side caching to stay snappy. Occasionally the filter state gets desynced from what's actually in the DOM — usually after rapid filter changes or if you leave the tab open overnight. The data's there, the view just won't show it. Resolution Normal refresh won't cut it. You need a hard refresh to dump the cached state: Windows: Ctrl + Shift + R or Ctrl + F5 Mac: Cmd + Shift + R or hold Shift and click the reload button You'll know it worked if the board shows a brief loading spinner and your filters reset to default. The Actual Workaround Since hard refresh clears your filters, here's how we handle it without losing our place: Note your current filters — screenshot if needed, or just remember the tech/date range Hard refresh the page Reapply filters one by one — don't rush, give each one a second to settle Check the count badge before moving to the next filter Pro tip: We keep a saved filter set called "Today's Active" that we can reapply in two clicks. If you're not using saved filters yet, you're making this harder than it needs to be. Also worth mentioning: pinning the dispatch board tab and never closing it seems to make this worse — we've started doing a hard refresh first thing every morning as preventative maintenance. When This Isn't the Fix If jobs are still missing after hard refresh, check ts-016 — Jobs Disappearing from Dispatch Board After Refresh. That's a different issue where the jobs actually aren't loading from the server. Status Engineering is aware and working on filter state persistence in 3.4. No ETA yet, but this workaround has been solid for us in the meantime.dispatchworkaroundcache-clearrefreshhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK155/sso-login-failing-for-newly-provisioned-usersWed, 06 May 2026 06:56:00 GMTarticle:e17e7105-b0dd-48bd-8209-55c8096cf092Summary: SAML authentication fails for users created within the last hour due to directory sync lag between the identity provider and FieldPulse. Symptoms Newly provisioned users receive "Authentication failed" or "User not found" errors when attempting SSO login. The error occurs despite the user appearing in the FieldPulse admin user list. Users provisioned more than 60 minutes prior log in successfully via SSO. Manual password login works as a temporary bypass. Affected Platforms All SAML 2.0 identity providers (Okta, Azure AD, OneLogin, Ping Identity) FieldPulse web application and mobile app Versions: 3.2.0 — present Cause A caching layer introduced in 3.2.0 to reduce directory query load is not invalidated when new user records are created via SCIM provisioning or manual admin invitation. The cache TTL is set to 60 minutes. As a result, authentication requests for users created within that window fail because the SAML assertion cannot be matched to a cached user record. Resolution No immediate configuration change is available. Two workarounds are documented below. Workaround Wait period: Advise users to wait 60 minutes after provisioning before their first SSO login. Manual cache clear (admin only): Navigate to Settings > Security > SSO Configuration and click Clear Directory Cache . This forces immediate cache invalidation for the entire organization. Note: This action is logged in the audit trail. Temporary password login: Users can set a FieldPulse-native password via the password reset flow and log in directly while waiting for cache expiration. Status Under investigation. Engineering has identified the root cause. A fix targeting cache invalidation on SCIM POST /Users and PUT /Users events is scheduled for release 3.3.0. No patch release is planned for 3.2.x given the availability of workarounds. Last updated: 2026-04-23provisioningSSOsamlloginhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK156/role-permission-changes-not-taking-effect-immediatelyWed, 06 May 2026 06:56:00 GMTarticle:e342f4b6-9bc5-4a2c-8fb8-c330dc43ec25Hi there! Happy to help with this one — it's a common point of confusion. Summary: After updating a user's role or permissions in Account Settings > Users & Roles , the changes may not appear to take effect immediately for that user. Symptoms User still cannot access newly permitted features User retains access to features they were removed from Dashboard or menu items remain unchanged after refresh Cause Role permissions are cached aggressively at the session level to maintain performance. When you save permission changes, the cache is invalidated, but existing active sessions are not terminated . The user must start a fresh session to pick up new permissions. Resolution Ask the affected user to: Log out completely from FieldPulse (click their profile > Sign Out ) Close the browser tab or fully close the mobile app Log back in They should now see the updated permissions reflected. For Admins If you need changes to apply across many users immediately, you can use Force Logout All Sessions from Account Settings > Security . Note this will sign out all users in your organization, so use during low-activity periods. Status Known behavior — we're evaluating session-level cache invalidation for a future release. No ETA yet, but this article will be updated when improvements ship. Let me know if you're still seeing issues after the user re-authenticates!adminrolescachepermissionshttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK157/audit-log-not-capturing-bulk-editsWed, 06 May 2026 06:56:00 GMTarticle:d79d4200-e11b-473e-a0cc-dcce0fc53a7dSummary: Bulk edit operations performed via the web application are not being recorded in the Audit Log , creating compliance gaps for organizations requiring complete change tracking. Symptoms The following bulk actions currently bypass audit trail capture: Bulk status updates to work orders (e.g., marking 50+ jobs "Completed") Bulk technician reassignment via Dispatch Board Bulk customer tag additions or removals Bulk inventory adjustments via CSV import Individual record edits continue to log correctly. The omission is specific to batch operations. Affected Versions FieldPulse 3.2.0 – 3.2.4 (all platforms) Cause The bulk operation handler executes database writes through an optimized path that bypasses the audit logging middleware. A refactor of the bulk processing pipeline in 3.2 introduced this regression. Resolution No user-side fix is available. Audit completeness cannot be restored retroactively for bulk operations performed during the affected window. Workaround For compliance-critical environments, avoid bulk operations until resolved. Execute changes individually, or maintain external change documentation for bulk actions. See related workaround: Manual Sync for Stale Mobile Data (process guidance) Status Fix targeted for 3.3.0. Engineering has implemented middleware interception for bulk handlers; currently in QA validation. Release anticipated mid-May 2026. Last updated: April 28, 2026bulk-editcomplianceaudit-loghistoryhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK151/large-work-order-lists-timing-outWed, 06 May 2026 06:55:00 GMTarticle:7a23abfb-15ec-4d40-88af-cfaae754d613Summary : Users with large work order databases experience timeouts when loading unfiltered list views containing 10,000 or more records. Symptoms The Work Orders list displays a loading spinner indefinitely or returns an error after 30–60 seconds Browser console shows 504 Gateway Timeout or Request aborted Issue occurs most frequently on initial page load with no filters applied Smaller filtered subsets (e.g., "This Week") load normally Affected Versions FieldPulse 3.2.0 – 3.2.4. Reported primarily on web dashboard; mobile impact minimal due to default pagination. Cause The list view performs aggregation queries (count by status, total value calculations) across the full dataset before applying pagination. With large datasets, these queries exceed the 30-second query timeout threshold. Resolution Engineering has identified the root cause. Fix targeted for 3.3.0 (release scheduled late May 2026). Workaround Until the fix is deployed: Navigate to Work Orders > List View Before the timeout occurs, apply a date filter (e.g., "Last 30 Days") via the Filter panel Bookmark this filtered URL for faster subsequent access For bulk operations on large datasets, use the API pagination workaround or export via Reports > Work Order Export Status : Under investigation. Fix targeted for 3.3.0.performancepaginationtimeoutlist-viewhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK152/map-view-freezing-with-100-active-jobs-plottedWed, 06 May 2026 06:55:00 GMTarticle:1cce9b8f-da3c-47ea-876b-b7a711cfb3e8Summary The Dispatch Map view becomes unresponsive or crashes when displaying more than 100 active jobs simultaneously, particularly affecting operations with large geographic coverage or high job density. Symptoms Browser tab freezes within 3–5 seconds of loading the Dispatch Map Map tiles render but job markers remain in a loading state indefinitely Chrome displays "This page is unresponsive" warning; Safari shows "This webpage is using significant memory" Issue is more pronounced on lower-spec machines or when multiple browser tabs are open Zooming or panning the map triggers additional freeze events Affected Versions / Platforms FieldPulse Web App 3.1.2 – 3.2.0 Chrome 120+, Safari 17+, Edge 120+ Windows 10/11, macOS 13+ Not affected: Mobile app map view (uses native rendering) Cause In my experience working with organizations that have scaled to 50+ technicians, this issue stems from how the legacy map rendering engine handles marker clustering. Prior to version 3.2, the platform rendered each job as an individual DOM marker element rather than using canvas-based clustering. At 100+ markers, the browser's memory footprint exceeds 500MB for the map tab alone, triggering garbage collection cycles that manifest as UI freezing. What I typically recommend understanding is that this is fundamentally a client-side rendering limitation, not a data loading issue. The API returns the job data efficiently; the bottleneck occurs during visualization. Resolution Immediate mitigation (no update required): Apply map filters before viewing — Filter by Technician , Status , or Date Range in the left panel to reduce rendered markers below 75 Use Territory Views — Configure Territory-based dispatch boards to auto-filter jobs by geographic region Disable live location tracking — Toggle off "Show technician locations" in the map layer menu (reduces marker count by ~30%) Permanent fix: Update to FieldPulse 3.2.1 or later, which introduces canvas-based marker clustering with automatic level-of-detail reduction. In my experience deploying this across multiple implementations, the new renderer maintains 60fps with 500+ markers. Navigate to Settings > System > Updates Verify current version; if below 3.2.1, select Update Now Clear browser cache (Ctrl+Shift+R or Cmd+Shift+R) to ensure new map assets load Test Dispatch Map with your typical job volume Workaround For organizations that cannot update immediately, what I typically recommend is a two-board workflow: use the List View for high-volume dispatching and reserve the Map View for route verification with filtered subsets. This has proven effective for teams managing 150+ daily jobs across our client base. Note: The workaround does have limitations — you lose the visual geographic context during initial assignment, which some dispatchers find disruptive. I acknowledge this is not ideal for operations where proximity-based assignment is critical. Status Resolved in 3.2.1 — Canvas-based clustering implemented. If you continue experiencing freezes after updating, please verify that your browser meets our supported browser requirements and that hardware acceleration is enabled in browser settings.performancefreezingmarkersmaphttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK153/barcode-scanner-disconnecting-intermittently-via-bluetoothWed, 06 May 2026 06:55:00 GMTarticle:61b57d2c-776c-4e76-88c3-ec7d15a15e59Pro tip: if your Bluetooth scanner keeps dropping out in the field, it's almost never the scanner itself — it's your phone trying to be helpful by saving battery. What you're seeing Scanner pairs fine, works for 10–20 minutes, then suddenly stops scanning. Sometimes it reconnects on its own, sometimes you have to re-pair it. Super annoying when you're in the middle of a job and need to check parts. Why it happens Most modern phones aggressively power-manage Bluetooth connections when the screen is off or when the FieldPulse app isn't in the foreground. The scanner thinks it's still connected, but the phone has basically put that connection to sleep. When you try to scan, nothing happens until you wake the phone back up. How to fix it iPhone users: Settings > Bluetooth > tap the (i) next to your scanner Make sure "Connect to This iPhone Automatically" is enabled Go to Settings > General > Background App Refresh and ensure FieldPulse is allowed Pro tip: disable "Low Power Mode" in battery settings — it nukes Bluetooth reliability Android users: Settings > Apps > FieldPulse > Battery Set to "Unrestricted" or "No restrictions" (exact wording varies by manufacturer) Settings > Bluetooth > gear icon next to your scanner Enable "Phone audio" or similar to keep the connection alive Scanner-specific: Some Zebra and Honeywell scanners have a "keep alive" interval you can configure in their companion app. If yours supports it, drop it from 300 seconds to 60 seconds. Burns a bit more battery but stays connected. If nothing else works Some Samsung and Xiaomi devices are just brutal with Bluetooth power management. If you're on one of those and still having issues, the only reliable fix I've found is keeping the FieldPulse app open and the screen awake while scanning. Not ideal, but it works. I've been running scanners in the field for six years across three different companies. This pattern is consistent enough that I always disable battery optimization for FieldPulse on every new device during onboarding. Saves a lot of headaches later.scannerhardwarebluetoothdisconnecthttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK154/label-printer-not-detected-after-system-updateWed, 06 May 2026 06:55:00 GMTarticle:eda23a5d-bdf0-4c08-baf4-45930d57000aWe've seen this hit several teams after recent Windows updates. Zebra label printers (ZD410, ZD420, GX420d) suddenly vanish from Windows device manager or show as "Unknown Device." Here's what works. What You'll See Printer absent from Windows Printers & Scanners "USB Device Not Recognized" notification on boot FieldPulse showing "No printer found" despite cable connection Root Cause Windows Update KB5055523 (and related cumulative updates) invalidated driver signatures for Zebra Setup Utilities versions older than 1.1.9. The driver installs but fails to load. The Fix Download Zebra Setup Utilities v1.1.9 or later from Zebra's support site. Uninstall existing Zebra driver via Device Manager → Universal Serial Bus controllers → Zebra Technologies (right-click, Uninstall, check "Delete driver software"). Reboot. Run new Zebra Setup Utilities installer with printer connected and powered on . Verify in FieldPulse: Settings → Printing → Test Print . If You Can't Update Drivers Immediately Temporary workaround: Roll back the Windows update (Settings → Windows Update → Update History → Uninstall Updates), then pause updates for 7 days until driver update is deployed. Prevention Add Zebra Setup Utilities to your patch management allow-list for auto-updates. Driver signature enforcement isn't optional on Windows 11 24H2+, so staying current is mandatory. Pro tip: Bookmark the Zebra driver RSS feed—Zebra typically posts compatibility updates 2–3 weeks before Microsoft's Patch Tuesday.label-printerdriverdetectionupdatehttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK148/date-filter-on-reports-not-respecting-time-zoneWed, 06 May 2026 06:54:00 GMTarticle:d2034cb4-5698-4265-b290-9d15936547fbSummary: Date range filters in reports are applying UTC boundaries rather than the user's configured time zone, causing data to appear offset by several hours. Symptoms Work orders completed late in the evening appear in the following day's report Morning appointments are excluded when filtering for the current date Report totals differ from expected values when filtering by date range Time zone setting in Account > Preferences > Regional Settings is correctly configured but not honored Affected Versions FieldPulse 3.2.0 – 3.2.4. All report types. Web application only; mobile reports are not affected. Cause The reporting engine's query builder converts date range inputs to UTC before filtering against the database timestamp fields. The conversion step is not applying the user-level time zone offset. Workaround Adjust your date range to compensate for the UTC offset: Calculate your time zone's offset from UTC (e.g., Eastern Daylight Time is UTC-4) Extend your date range by one day on each boundary Export to CSV and filter locally in your spreadsheet application Alternatively, use the API to retrieve data with explicit UTC timestamps and apply time zone conversion in your external tool. See How do I retrieve custom field values from a work order via the API? for related patterns. Status Fix targeted for FieldPulse 3.3.0. The engineering team has implemented time zone-aware date parsing; currently in QA validation.timezonedate-rangefilterreporthttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK149/csv-export-truncating-long-notes-fieldsWed, 06 May 2026 06:54:00 GMTarticle:a89f2af4-f22e-474d-b393-3058cb59c783Summary When exporting work orders or service reports to CSV format, text entered into Notes fields that exceeds 32,767 characters is being silently truncated, resulting in incomplete data in the exported file. Symptoms You may notice this issue if: Exported CSV files contain notes that appear to end abruptly with no closing punctuation or complete thought Comparing the exported data against the original record in FieldPulse reveals that the final portions of lengthy notes are missing Character counts in exported cells consistently stop at or near 32,767 No error or warning is displayed during the export process Affected Versions and Platforms This behavior has been observed across: FieldPulse Web Application versions 3.1 through 3.2.2 All supported browsers (Chrome, Firefox, Safari, Edge) Both standard and custom report exports Cause In my experience, this limitation stems from the underlying CSV generation library used by FieldPulse's reporting engine, which enforces a maximum cell length of 32,767 characters to maintain compatibility with older spreadsheet applications, particularly Microsoft Excel. While this was originally implemented as a safeguard, it does not account for modern use cases where technicians may enter extensive diagnostic notes, multi-step repair procedures, or detailed customer interaction logs. What I typically recommend is understanding that the data itself is not lost in FieldPulse — the full notes remain intact in the database and are visible within the application. The truncation occurs only at the point of CSV generation. Resolution There are several approaches to address this depending on your specific needs: Option 1: Use PDF or Excel Format (Recommended) For reports containing lengthy notes, I generally advise selecting Excel (.xlsx) or PDF as your export format rather than CSV. These formats do not impose the 32,767 character limitation and will preserve complete notes. Navigate to Reports > Work Orders (or your desired report) Click Export Select Excel (.xlsx) from the format dropdown Complete the export Option 2: Split Long Notes Before Export If CSV format is strictly required for downstream processing, consider establishing a workflow where technicians break lengthy entries into multiple shorter notes or use structured fields for detailed information rather than free-form notes. Option 3: API Retrieval For automated integrations where CSV is the expected format, what I typically recommend is retrieving the data via the FieldPulse API, which returns complete field values without truncation. You can then transform this data into your required format using your own tooling. Workaround Until a permanent fix is implemented, if you must use CSV exports and cannot switch formats: Export to Excel (.xlsx) format first Open in Excel or compatible spreadsheet application Save or export as CSV from that application This two-step process preserves the full content because Excel's export handles the conversion differently than FieldPulse's native CSV generator. Status This issue has been logged with our engineering team. A fix targeted for release 3.3 will increase or remove the character limit for CSV exports. I will update this article when additional information becomes available. In the meantime, if you have specific reporting workflows that are blocked by this limitation, please reach out through your normal support channels and reference this article. We want to make sure you're set up for success, and there may be additional configuration options depending on your account setup.notescsvexporttruncationhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK150/dashboard-load-times-slow-during-peak-hoursWed, 06 May 2026 06:54:00 GMTarticle:0c4af602-fada-40d9-a2e8-2c05cb3bebd4Hi there! If you're noticing that the Dashboard takes longer to load during busy mornings or right after your team clocks in, you're not alone. Happy to help explain what's happening and how to improve things. Summary Dashboard widgets timeout or load slowly when concurrent users exceed 500. Symptoms Dashboard page takes 10–30 seconds to fully render Individual widgets show spinning loaders or "Unable to load data" messages Issue occurs consistently between 7:00–9:00 AM and 4:00–6:00 PM local time Refreshing the page occasionally helps, but not consistently Affected Environments Web app (all browsers) Particularly noticeable for users with 10+ dashboard widgets configured Organizations with 50+ active technicians Cause During peak usage windows, the real-time aggregation queries that power dashboard widgets compete for database connection pool resources. When concurrent requests exceed our current capacity threshold, some queries queue rather than execute immediately, resulting in the delays you're seeing. Immediate Resolution Steps Here are a few things you can try right now: Reduce widget count: Click Edit Dashboard and remove widgets you don't check daily. Each widget makes a separate query. Adjust date ranges: Widgets set to "Last 30 Days" or "This Quarter" require heavier aggregation. Try "Today" or "This Week" during peak hours. Stagger team login times: If possible, have dispatchers or supervisors log in 15 minutes before or after the main technician rush. Clear browser cache: Press Ctrl+Shift+R (Windows) or Cmd+Shift+R (Mac) to hard-refresh if you see stale data. Longer-Term Improvements Our engineering team has identified this as a priority. We're implementing: Query result caching for dashboard widgets (rolling out in 3.3.2) Connection pool scaling during known peak windows Optional "Light Dashboard" mode with pre-aggregated snapshots Status Fix targeted for release 3.3.2 (mid-April). I'll update this article once the release is live. If you're seeing slowness outside of peak hours or these steps don't help, please reach out to Support with your account ID and the specific times you experienced issues. We can check if there's something else going on.peakload-timeperformancedashboardhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK144/webhook-not-firing-on-job-completionWed, 06 May 2026 06:53:00 GMTarticle:98d931cb-59d9-404a-8f3f-c6d74a1a4133yeah this one tripped me up too when I first looked at it. if you're subscribed to the work_order.status_changed event and expecting a webhook when a job hits "Completed" — but you're only seeing it sometimes — this is probably why. Summary Webhooks fail to fire when job completion occurs via bulk action or API call, while manual completion in the UI works fine. Symptoms Webhook fires when a technician marks a job complete in the mobile app or web UI No webhook received when completing jobs via Bulk Actions on the dispatch board No webhook received when updating status via PATCH /api/v2/work_orders/{id} or PUT Webhook fires inconsistently for jobs completed through automated workflows Affected Versions FieldPulse 3.1.x - 3.2.0. API v2.0 and v2.1 affected. Root Cause The webhook event system currently hooks into the UI-level status transition handler. Bulk actions and direct API updates use a different code path that bypasses the event emitter — yeah, I know, it's not great. The team's tracking this as ENG-4421 internally. There's actually a related edge case here: if you're using Zapier, this same bug means the "Job Completed" trigger won't fire for API-completed jobs either. The Zapier integration uses webhooks under the hood, so it inherits the same limitation. Workaround Until the fix ships, you've got a couple options: // Option 1: Poll for status changes // Query every 60 seconds for work orders with status=completed // and updated_at > your last check timestamp GET /api/v2/work_orders?status=completed&updated_after=2026-02-27T12:00:00Z Option 2: If you're completing jobs via your own integration, fire a custom webhook from your side after the PATCH returns success. Not ideal, but it keeps your downstream systems in sync. Status Fix targeted for 3.2.1 — currently in QA. The change moves status change events to a database-level trigger so all code paths emit consistently. I'll update this thread when the release candidate is available. If you're blocked on this and need the RC build, ping me directly.job-completionapiwebhookeventhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK145/api-rate-limiting-causing-incomplete-data-exportsWed, 06 May 2026 06:53:00 GMTarticle:49f4190a-2b0c-486c-aa5d-a31cfc73bd56If you're pulling large datasets via the API and noticing your exports are mysteriously truncating — yeah, this one tripped me up too when I first looked at it. The symptoms look like a successful request (you get a 200, maybe even a full-looking JSON payload), but then you realize you're missing thousands of records. Summary API rate limiting is causing large data exports to terminate early, returning partial datasets without clear error signaling. Symptoms Export scripts report "success" but row counts don't match expected totals Last page of paginated results returns fewer records than page_size , with no next URL Response headers show X-RateLimit-Remaining: 0 but status code remains 200 Same export run twice produces different record counts Affected Versions FieldPulse API v2.0 and v2.1. Particularly impacts endpoints with high data density: GET /work_orders with expanded customer data GET /customers with custom fields included GET /time_entries across date ranges > 90 days What's Actually Happening Here's the gotcha: the API has a secondary limit on "complexity points" that isn't surfaced in the standard rate limit headers. When you request heavy expansions (nested customer objects, line items, form responses), you're burning through this budget faster than the standard 1000 req/min limit suggests. Once you hit the complexity ceiling, the API quietly truncates your response rather than erroring. Not ideal — we're pushing to get this changed to a proper 429 with a Retry-After header, but that's still in review. Immediate Workaround Until the fix ships, you'll want to: # Add explicit throttling between paginated requests import time def fetch_all_work_orders(): results = [] url = "https://api.fieldpulse.com/v2/work_orders?page_size=50" # ^ smaller page size, avoid expansions in initial fetch while url: resp = requests.get(url, headers=auth_headers) data = resp.json() results.extend(data['results']) # Force 200ms delay regardless of rate limit headers time.sleep(0.2) # Check for truncation signal: fewer results than page_size if len(data['results']) 'next'): print(f"Warning: possible truncation at {url}") time.sleep(2) # back off aggressively continue # retry same page url = data.get('next') return results Then fetch related data (customer details, etc.) in a second pass using batch endpoints where possible. Yeah, it's more requests, but each one stays under the complexity radar. Better Pattern (Recommended) If you're doing regular large exports, use the API pagination workaround pattern which includes adaptive backoff based on response size. Also consider: Webhook-based sync instead of bulk export for ongoing replication Incremental exports using modified_since parameter Our new bulk export endpoint (beta, /exports/jobs ) — async, no rate limit issues, CSV or JSON output Status Engineering is tracking this as API-2847 . Target behavior: return 429 with Retry-After and a clear error message when complexity limits are hit. No firm release date yet — I'll update this article when I know more. Hit me up in the comments if you're seeing different behavior or found another pattern that works.paginationapirate-limitexporthttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK146/zapier-trigger-missing-custom-field-valuesWed, 06 May 2026 06:53:00 GMTarticle:e1b9df9d-bb5f-4ec2-ab0f-821f8f434db2Yeah this one tripped me up too when I first looked at it. The Zapier integration for FieldPulse is solid overall, but there's a weird edge case with how custom fields get serialized when they're passed to the Zap trigger payload. The Problem When you set up a Zap that triggers on a work order event (like work_order.created or work_order.status_changed ), any custom fields that contain line breaks or certain special characters simply don't appear in the data Zapier receives. Not empty — completely missing. This breaks Zaps that rely on custom field values for routing or data transformation. Symptoms Your Zap runs successfully, but the custom field you need is absent from the trigger data The field shows up in FieldPulse's UI and API, but Zapier's test data shows it as missing Fields with single-line values work fine; multi-line text fields are the ones that vanish Zapier's "Find Data" step may show the field, but the actual trigger payload omits it Root Cause Here's what's happening: FieldPulse's webhook payload serializes custom fields as a nested object, but the Zapier parser has trouble with unescaped newlines in JSON string values. The webhook fires correctly and the data leaves our servers intact, but somewhere in the handoff to Zapier's ingestion layer, fields with \n or \r\n get dropped silently rather than throwing an error. I dug into this with our platform team last month. The webhook payload looks like this: { "work_order_id": "wo_abc123", "custom_fields": { "field_001": "Single line value - this works fine", "field_002": "Line one\nLine two\nLine three - this disappears" } } Zapier's parser expects the JSON to be fully escaped. When it hits that unescaped newline, it treats the field as malformed and skips it rather than surfacing an error. Super frustrating because it looks like the data was never sent. Resolution We've got a fix going out in API v2.1 (should be live by end of March). The webhook payload will properly escape newlines as \\n before transmission, which Zapier handles correctly. In the meantime, here are your options: Option 1: Use a Webhook Catch Hook Instead (Recommended) Bypass Zapier's native FieldPulse trigger and use a Webhooks by Zapier "Catch Hook" instead. This gives you the raw payload, which you can then parse with a Code by Zapier step or Formatter if needed. In your Zap, choose "Webhooks by Zapier" → "Catch Hook" Copy the webhook URL and add it in FieldPulse under Settings → Integrations → Webhooks Set the event type you need (e.g., work_order.status_changed ) In your Zap, add a "Code by Zapier" step to parse the custom fields: const customFields = inputData.rawBody ? JSON.parse(inputData.rawBody).custom_fields : {}; return { custom_field_values: JSON.stringify(customFields) }; Yeah, it's an extra step, but you get all your data. Option 2: Sanitize Your Custom Field Input If you control how data enters those custom fields, strip newlines before save. Replace with | or ; or something your Zap can split on later. Not elegant, but it works today. Option 3: Use the FieldPulse API Directly If this is a critical workflow, consider building against our API directly instead of Zapier. You get full control over parsing and can handle edge cases properly. Check out How do I paginate through a large list of work orders via the API? for a starting point. Status Fix targeted for API v2.1 (webhook payload serialization update). I'll update this article once it's live. If you're blocked on this, ping me directly or open a dev support ticket and reference this issue — we can enable the escaped payload format on your account early. Related How do I trigger a Zap when a work order status changes to "Completed"? Webhook payload is missing custom fields — is this expected behavior? API v2.1 Now Available with Webhook Improvementstriggerwebhookzapiercustom-fieldshttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK147/work-order-summary-report-showing-incorrect-totalsWed, 06 May 2026 06:53:00 GMTarticle:aa58b8f1-4b25-4bfd-8af0-314681105763Hi there! Happy to help with this one — it's a question we see fairly often when teams are reconciling their monthly numbers. Summary The Work Order Summary Report may display totals that appear lower than expected because work orders in certain transitional statuses are excluded from the calculation by default. Symptoms Report totals do not match the number of work orders visible in the dispatch board Revenue figures appear understated compared to invoice totals Discrepancy of 5–15% between expected and reported counts Issue most noticeable when filtering by date ranges that include recently completed jobs Affected Versions FieldPulse 3.0 – 3.2.2 (web application) Cause The summary report applies a default status filter that excludes work orders in "In Progress" or "Pending Parts" states. If a work order moves to Completed but has not yet been invoiced, it may also be temporarily excluded from certain calculation paths. Resolution Open Reports > Work Order Summary Click Filters in the top right Under Status , select "Include All Statuses" or manually check the statuses you need Click Apply Filters and regenerate the report Verify totals against your dispatch board or invoice records If you need to save this configuration for future runs, click Save Filter Set and name it descriptively (e.g., "Monthly Reconciliation — All Statuses"). Still Seeing Discrepancies? If totals remain incorrect after adjusting filters, check whether: The Date Range filter is using "Created Date" vs. "Completed Date" — these can shift results significantly Any work orders were bulk-edited during the reporting period (these may temporarily desync from the reporting cache) Feel free to reply here or open a ticket if you'd like us to audit a specific report against your account data. We're here to help!reporttotalssummarycalculationhttps://verint14-pre-03.socialedgeconsulting.io/product-fieldpulse/a/troubleshooting-known-issues/TK140/arrival-notification-sent-before-technician-departsWed, 06 May 2026 06:48:00 GMTarticle:811150aa-1f14-4fa5-85eb-01d9ab611671Summary: Customers receive "Technician is on the way" or "Technician has arrived" notifications while the technician is still en route or has not yet departed, caused by GPS accuracy drift triggering geofence boundaries prematurely. Symptoms Customer receives arrival notification 5–20 minutes before technician actually arrives on site Notification fires while technician is still driving to the job In some cases, notification fires when technician is at a nearby location (gas station, previous job site, etc.) Technician location in Dispatch > Live Map shows correct position, but arrival status was triggered Issue reported more frequently in urban canyons, rural areas with poor satellite coverage, and during weather events Affected Platforms FieldPulse Mobile v3.1.0 – v3.2.4 (iOS and Android) iOS 16.5+, Android 13+ Geofence radius: default 150m (configurable in Settings > Notifications > Geofence ) Root Cause I have confirmed that this issue occurs when the device's GPS accuracy degrades below 50 meters. Under these conditions, the reported location can fluctuate by 100–300 meters, causing the geofence algorithm to register a boundary crossing. The geofence trigger does not currently validate location accuracy before firing the notification event. I can reproduce this when: GPS accuracy reads >50m in the FieldPulse mobile app (visible in Settings > Diagnostics > Location ) Device enters power-saving mode, which reduces GPS polling frequency Device transitions between Wi-Fi and cellular positioning Resolution This issue is resolved in FieldPulse Mobile v3.2.5, released 2026-02-05. To verify your version and update: Open FieldPulse mobile app Tap Profile > About Confirm version is 3.2.5 or higher If outdated, update via App Store (iOS) or Google Play (Android) The fix introduces accuracy threshold validation: geofence triggers now require GPS accuracy ≤30m before firing arrival notifications. Workaround (for versions prior to 3.2.5) If immediate update is not feasible, I have confirmed that increasing the geofence radius reduces false triggers: In web app, navigate to Settings > Notifications > Customer Notifications Expand Geofence Settings Change Arrival Radius from 150m to 250m Save changes Note: This workaround reduces sensitivity and may delay arrival notifications slightly. It does not eliminate all false triggers in high-GPS-drift environments. Validation Steps After Update Enable Settings > Diagnostics > Enable Location Logging on technician device Complete a test job with known GPS-challenged route Review timestamp alignment between actual arrival and notification sent Submit logs via Settings > Diagnostics > Send Feedback if discrepancy >2 minutes persists Related Documentation What's New in the Mobile App — Q3 Update (geofence improvements) How are you using customer notifications to set expectations? Status: Resolved in 3.2.5arrivalgeofencegpsnotification