> For the complete documentation index, see [llms.txt](https://help.fielddoc.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.fielddoc.org/essentials/integrations-beta.md). # Integrations (beta) {% hint style="info" icon="circle-user" %} Feature is available for **Standard** and **Aggregator** subscriptions. {% endhint %} ## Connect FieldDoc to ArcGIS Online FieldDoc’s ArcGIS Online integration allows you to publish FieldDoc Activity data to ArcGIS Online (AGOL) as hosted feature services. Once a feature service is established, you can refresh it with updated FieldDoc data while preserving the maps, dashboards, styles, and other configurations you have built in ArcGIS Online. This workflow is particularly useful for programs that collect Activity data from multiple organizations in FieldDoc and want to maintain a consolidated mapping or reporting layer in ArcGIS Online. ### Before you begin Before creating an ArcGIS Online export, determine: * **Which FieldDoc Workspace contains the data you want to publish** * **Which ArcGIS Online account should own the resulting feature service** * **Whether you are creating a new feature service or connecting to an existing one** * **Which FieldDoc fields and metrics you want to make available in ArcGIS Online** For programs receiving data from multiple partners, we generally recommend creating the ArcGIS Online connection at the program-management level rather than asking each contributing organization to create its own connection. For example, if partner organizations share Activities with a Program through Pacts, the program team can publish the consolidated program dataset to ArcGIS Online from the Workspace where the program data is managed. Contributing organizations do not need their own ArcGIS Online connections for their data to be included. *** ### 1. Connect your ArcGIS Online account FieldDoc must first be authorized to access the ArcGIS Online account that will own the feature service. Open **Connections** in FieldDoc and connect the appropriate ArcGIS Online account. A few things to know about connections: * The ArcGIS Online account you connect will own any new feature service created from that connection. * You can connect more than one ArcGIS Online account. * When creating an export, you can select which connected account to use. * Access to manage ArcGIS Online connections is limited to users with the appropriate permissions in the FieldDoc Workspace. Organizations contributing data through Pacts do not automatically see or manage these connections. If your organization has specific requirements about who may connect, disconnect, or reconnect ArcGIS Online accounts, establish those responsibilities as part of your program's data-management procedures. Removing a connection may interrupt an established data workflow, so connection management should generally be limited to designated administrators. ### 2. Start from the highest useful level of your data For most program-level ArcGIS Online workflows, we recommend exporting from the highest FieldDoc level that contains the complete dataset you want to manage. For example, a program receiving Activities from several partner organizations through Pacts can use the program's **Activities** table as the source for the ArcGIS Online feature service. This approach is usually easier than creating multiple narrowly filtered exports. Instead: 1. Publish the complete program dataset to ArcGIS Online. 2. Maintain a stable feature service containing the authoritative FieldDoc records. 3. Create filtered layers, maps, dashboards, or views in ArcGIS Online for specific audiences or purposes. This keeps the FieldDoc-to-ArcGIS Online connection relatively simple while allowing ArcGIS Online to handle visualization and presentation. ### 3. Create the ArcGIS Online export From the **Activities** table: 1. Select the **Import/Export** button in the upper-right corner. 2. Choose the option to export to **ArcGIS Online**. 3. Enter a name for the export. 4. If more than one ArcGIS Online account is connected, select the account that should own the feature service. 5. Choose whether to create a new feature service or use an existing compatible service. The export name is primarily an administrative convenience so your team can recognize and manage the connection later. #### Create a new feature service whenever possible For a new integration, we strongly recommend allowing FieldDoc to create a **new feature service**. FieldDoc creates the feature service using the schema expected by the integration. Once it has been created successfully, FieldDoc can continue refreshing that same service with updated data. Connecting to a feature service that was created independently in ArcGIS Online is more complicated. The existing service must be compatible with the fields, geometry, and API requirements used by FieldDoc. If the schemas do not match, ArcGIS Online may reject updates. If you already have an existing feature service that needs to become the destination for FieldDoc data, work with The Commons to confirm that the service is configured appropriately before establishing the connection. ### 4. Select the data to include During export setup, FieldDoc allows you to control which information is included. In most cases, we recommend keeping the default fields unless there is a specific field you know you do not need. FieldDoc sends information useful for identifying, reconciling, filtering, and analyzing Activities, including fields such as: * FieldDoc Activity ID * Activity name * Activity Type * Geometry * Centroid * Activity extent * User-supplied extent, when present * Completion date * Other Activity attributes selected during export The **FieldDoc Activity ID** is particularly important. It provides a stable identifier that can be used to reconcile a record in ArcGIS Online with the original Activity in FieldDoc. #### Geometry layers Activities are separated by geometry type. Depending on the options selected, the resulting feature service may contain layers for: * Points * Lines * Polygons * Centroids The centroid layer provides a simplified point representation of Activities and can be useful for dashboards, overview maps, or other visualizations where the full Activity geometry is unnecessary. FieldDoc also supports Pact geometries where applicable. ### 5. Include Metrics when needed Metrics can also be included in the ArcGIS Online export. When included, Metrics are delivered as a separate layer. If the centroid layer is also included, this will generally appear as an additional fourth or fifth layer in the feature service. Metric records include the associated **FieldDoc Activity ID**, allowing Activity and Metric information to be joined or analyzed together in ArcGIS Online. This can support workflows such as: * Dashboard rollups * Summaries by Activity Type * Program performance reporting * Metric totals by geography * Custom pop-ups * Program-level analytics ArcGIS functionality such as joins, views, and Arcade expressions can then be used to create more specialized reporting and visualization experiences. If you know the ArcGIS Online reporting or dashboard requirements in advance, it is useful to define them before finalizing the FieldDoc export schema. ### 6. Review the staged export Before records are sent to ArcGIS Online, FieldDoc stages the export and provides a summary of what will be included. Use this screen as a data-quality check. FieldDoc may identify records that cannot be included or that contain potentially problematic data. Reviewing these records before publishing can help identify issues such as incomplete geometries or inconsistent data entry. The integration cannot resolve underlying data-quality problems automatically. Program teams should establish expectations for the information partners are responsible for entering and reviewing in FieldDoc. For example, programs should decide how Activity extent should be handled. FieldDoc may contain both: * An extent automatically calculated from the Activity geometry, using the geometry's measurement units * A user-entered extent intended to represent a different or more authoritative measurement If users will be allowed to supply their own extent values, establish that expectation early. Otherwise, a program may later have difficulty determining which measurement should be considered authoritative across Activities created by different organizations. A program Standard Operating Procedure can help document these decisions. After reviewing the summary, select **Stage** or continue with the export. ### 7. Publish the feature service Once confirmed, FieldDoc begins preparing and sending the data to ArcGIS Online. The export requires several steps behind the scenes, including preparing the different geometry layers and communicating with ArcGIS Online to create or update the feature service. The export may therefore take several seconds to complete. This is expected. When processing is finished, FieldDoc provides a link to the resulting ArcGIS Online feature service. You can then use that feature service to build: * Web maps * Dashboards * Experience Builder applications * Hosted feature layer views * Custom pop-ups * Other ArcGIS Online products *** ### 8. Refresh the feature service when FieldDoc data changes The ArcGIS Online integration does **not automatically publish every FieldDoc change immediately**. When Activities are added or edited in FieldDoc, an authorized user can return to the ArcGIS Online export and trigger a **refresh**. FieldDoc maintains a log of refresh events so the program team can see when the data was most recently synchronized. This manual workflow is intentional. For programs receiving data from outside organizations, an immediate automatic sync can create problems. For example, a partner might temporarily upload draft or test data that should not yet appear in a public-facing map. A more controlled workflow might be: **Partner enters data → Program reviews data → Program refreshes ArcGIS Online** This provides a review point before changes reach the official ArcGIS Online dataset. Scheduled or more automated workflows may also be appropriate for some programs, but programs should consider their review and quality-control process before adopting them. *** ### What happens to existing ArcGIS Online maps when you refresh? Refreshing the feature service updates the data in the existing service rather than requiring you to rebuild your ArcGIS Online products. As long as the underlying fields used by your ArcGIS Online configuration remain stable, items connected to the service can continue to use their existing: * Symbology * Filters * Pop-ups * Dashboards * Views * Arcade expressions * Map configurations In other words, you can configure the ArcGIS Online presentation once and continue refreshing the FieldDoc data underneath it. Avoid unnecessarily changing the exported field structure after downstream ArcGIS Online products have been built. *** ### Optional filtering FieldDoc allows Activity records to be filtered before an export. For most program-wide integrations, however, filtering at export is not necessary. A simpler architecture is often: **FieldDoc program dataset → complete AGOL feature service → filtered AGOL views and maps** This gives the program one stable source layer while allowing different ArcGIS Online products to display different portions of the dataset. Export-level filtering may still be appropriate when records must be separated for security, contractual, or program-management reasons. *** ### Managing images and attachments Images require additional consideration. ArcGIS Online supports feature attachments, but transferring raw image files between systems through an API can create performance and management challenges. Depending on program requirements, possible approaches include: * Sending files as ArcGIS Online attachments * Hosting images at a permanent location and including the image URL as a field in the ArcGIS Online layer * Maintaining images in FieldDoc while using ArcGIS Online primarily for spatial visualization and analysis Programs with significant image requirements should define how images will be stored and displayed before finalizing the integration. *** ### Recommended program workflow For a multi-organization program, we generally recommend the following model: **1. Partners manage Activities in FieldDoc** Each participating organization creates and maintains its Activity information. **2. Partners share Activities to the program** Activities are shared with the program through Pacts. **3. Program staff review contributed data** Program managers review the Activities and address any data-quality issues before publication. **4. The program maintains one ArcGIS Online connection** A designated ArcGIS Online account owns the program feature service. **5. The complete program dataset is published** The program's Activities table becomes the primary source for the ArcGIS Online feature service. **6. ArcGIS Online handles presentation** Program staff create maps, dashboards, filters, views, and other audience-specific products within ArcGIS Online. **7. Program staff deliberately refresh the data** After reviewing new or changed FieldDoc records, program staff trigger a refresh. This creates a clear boundary between **data management in FieldDoc** and **mapping and visualization in ArcGIS Online**. *** ### Data governance considerations Before launching an ArcGIS Online integration, programs should document a few basic data-management decisions. These may include: * Who owns the ArcGIS Online feature service? * Who is authorized to manage the FieldDoc-to-ArcGIS connection? * Who may trigger a refresh? * How frequently should the feature service be refreshed? * Does program staff review contributed Activities before refreshing? * Which FieldDoc fields are considered authoritative? * Should auto-calculated or user-entered Activity extent be used? * Which Metrics should be published? * How should images or attachments be handled? * Which ArcGIS Online maps or dashboards depend on the feature service? Answering these questions at the beginning of a program can prevent significant reconciliation work later. #### Data sharing agreements A separate data-sharing agreement with The Commons is not necessarily required simply to use the integration when data use is already governed through an existing agreement with The Commons. Program administrators should still determine whether agreements with their own partners, grantees, clients, or participating organizations establish additional requirements for publishing or sharing their data through ArcGIS Online. *** ### Summary The most reliable ArcGIS Online workflow is to treat FieldDoc as the source of program Activity data and ArcGIS Online as the visualization and analysis environment. For most programs: **Create Activities in FieldDoc → share through Pacts → review at the program level → publish a consolidated feature service → build ArcGIS Online views and dashboards → refresh deliberately as FieldDoc data changes.** Creating the feature service through FieldDoc at the beginning of the process provides the most reliable foundation for ongoing synchronization and allows your ArcGIS Online products to remain stable as the underlying program data evolves. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.fielddoc.org/essentials/integrations-beta.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.