Atlasemoji / DataSynch

Fixed geofence trial help

Use the home-page trial to create a real saved geofence, place it on the map, capture consented participants, and understand how geofence events can start operational workflows.

What is a geofence?

A geofence is a boundary on a map. It can be a small radius around a dock door, a booth, a warehouse yard, a campus, or a larger polygon around an operating area.

It is a trigger, not only tracking

When a consented phone, scanner, truck, plane, vessel, asset, or event enters or exits the boundary, Atlas can trigger email, webhook, alert, DataSynch event, exception, dispatch, CRM note, or another workflow.

Last known vs current location

The map can show the last known location immediately. Current location appears after the device/browser/app sends a new update, which can take a moment.

Consent matters

Do not track a friend, driver, visitor, or device unless that participant accepts the invite and agrees to location sharing. Participants must be able to stop sharing or revoke consent.

How a DataSynch geofencing program works

The program is a chain. Each part is reusable, inspectable, and separate from the others.

1
Program
2
Zones / WHERE
3
Subjects / WHO-WHAT
4
Rules & Actions
5
Events

Zones and Subjects each have their own source

Do not combine these questions. Zones answer WHERE the program applies. Subjects answer WHO or WHAT is evaluated there. Each side can use Atlas data or connected data independently.

Atlas Data

Use existing CRM, Locations, Items, Inventory, or Telemetry rows already stored in DataSynch.

Connected App

Use Google Sheets, Airtable, files, API/webhook, CRM, SFTP, or another source from the Integration connector catalog.

Saved Workflow

Use a DataSynch Integration workflow you already configured, including its credentials, source selection, mapping, and normalization.

Zones: WHERE does the program operate?

For DataSynch geofencing, Atlas Locations is the canonical operating table for real estate and place records. A Location is not the same thing as a geofence: the Location describes the place; a geofence supplies reusable spatial geometry around or within that place.

Typical Location records
  • • store / retail location
  • • distribution center / warehouse
  • • yard / dock / terminal / gate
  • • campus / jobsite / event venue
  • • service territory or other operational place
Location geography can resolve to
  • • saved latitude / longitude
  • • an address that Integration geocodes
  • • generated point-radius geometry
  • • an existing polygon / custom boundary
  • • another reusable saved geofence
Example: 300-store retailer

Do not hand-build 300 geofence forms. Import or connect the retailer’s place list, write those records into Locations, review geocoding/location exceptions there, then select all or some of those Location rows for the program. DataSynch can create reusable point-radius geometry for map-ready rows while preserving custom polygons or other boundaries where needed.

Program coverage choices
Selected locations: choose specific Atlas Location rows.
All Atlas locations: use every usable Location in the manifest.
Worldwide / no location filter: remove the program-level Location restriction. Spatial rules still require reusable geometry to produce entry/exit/dwell events.

The DataSynch table rule

Use these meanings consistently so programs start from sensible defaults instead of a blank “who knows?” state.

LocationsWHERE operational things happen.
CRMPEOPLE and ORGANIZATIONS.
ItemsWHAT something is.
InventoryWHAT EXISTS WHERE, including quantity/position context.
TelemetryWHAT IS HAPPENING and WHERE something is now.
GeofencesGEOMETRY and spatial tests.
ProgramsHOW those pieces are combined.

When to put imported data in Master Tables

Master Tables are the Atlas-side operating surface for imported or normalized business data.

Import into a Master Table when you want to:
  • • inspect the imported rows in Atlas
  • • review field mapping or normalization
  • • see exceptions and problematic records
  • • geocode or map the data
  • • reuse the records in other DataSynch operations
  • • maintain an Atlas-side operational copy
Use normalized workflow records directly when:
  • • the external application remains the authoritative source
  • • the workflow already maps the fields Geofencing needs
  • • you do not need a durable Atlas copy of every source row
  • • the data is transient telemetry or event traffic

Build a program: step by step

The full DataSynch flow is below.

1

Create or open a Geofencing Program

Open DataSynch → Geofencing → Programs. Create a program for one operational purpose such as shipment arrival, yard dwell, retail loyalty, asset movement, or field operations.
2

Define Zones: WHERE does it happen?

Open Zones. Choose selected Atlas Locations, all Atlas Locations, or worldwide/no location filter. If place data is missing, import or connect the store/facility/yard/site list and write it into Locations. Review rows that need geocoding, then prepare reusable point-radius zones or assign existing custom polygons/boundaries. Entry/exit/dwell behavior does not belong in the Zone record; it belongs in Rules & Actions.
3

Define Subjects: WHO or WHAT are we watching?

Open Subjects. The subject has its own source, separate from the Zone source. Retail Loyalty normally starts with CRM customers/members; shipment and yard programs commonly start from Integration/telemetry; warehouse assets commonly start with Inventory/Items plus telemetry where movement is required; field operations commonly start with CRM/mobile participants.
4

Choose the identity field

Select the stable field that identifies one subject record, for example customerId, shipmentId, vehicleId, assetId, participantId, or deviceId. The same subject must resolve to the same identity value on later location updates.
5

Make sure location data is available

The normalized record must provide usable geography. Common paths are latitude/longitude, a source address that Integration geocodes, a saved Atlas location relationship, or a device/telemetry position.
6

Build the Rule

Open Rules & Actions. Define WHEN entry/exit/dwell occurs, AT the selected zone, FOR the subject, and optionally IF business fields satisfy additional conditions.
7

Choose downstream behavior

Every matching rule creates a DataSynch geofence event. Enable notification dispatch when you want existing DataSynch notification rules/connectors to send matching Slack, email, webhook, or other configured notifications.
8

Review Events

Open Events to see the actual program, rule, subject, zone, event type, event time, and notification result. Use Integration/Monitor for upstream failures, mapping issues, or other exceptions.

Google Sheets → Geofencing

  1. 1. In Integration, choose Google Sheets and connect the Google account.
  2. 2. Select the spreadsheet and sheet/tab, then preview the rows.
  3. 3. Map the source fields to the normalized fields you want Geofencing to use.
  4. 4. Save the Integration workflow.
  5. 5. In Geofencing → Subjects, choose Connected App → Google Sheets.
  6. 6. Select the saved workflow.
  7. 7. Choose direct workflow use or require the workflow to write into a Master Table.
  8. 8. Enter the mapped identity/display fields and build the rule.

Airtable → Master Table → Geofencing

  1. 1. Connect Airtable and choose the base/table/view.
  2. 2. Preview the actual Airtable records.
  3. 3. Map Airtable fields to the desired Atlas fields.
  4. 4. Select CRM, Locations, Items, or Inventory as the import target.
  5. 5. Run/import the workflow and inspect the resulting Master Table.
  6. 6. In Geofencing, choose Atlas Data as the source.
  7. 7. Select the destination Master Table, identity field, zones, and rule.

Rule anatomy

WHEN
Shipment enters
AT
Receiving Yard
FOR
Inbound shipment subject
IF
appointmentStatus = scheduled
THEN
Create DataSynch geofence event + dispatch matching notification rules

The condition fields are evaluated against the normalized record that reached the geofencing runtime. For connected sources, make sure the Integration mapping produces the same field names used by the rule.

Notifications and downstream connectors

Geofencing rules create normalized DataSynch events. Notification dispatch then uses the existing DataSynch notification rules/connectors. Configure Slack, email, webhook, or other destinations there rather than storing endpoints or secrets inside a geofencing rule.

Open Integration

Data checklist before testing

The program has selected/map-ready Location zones, all-location coverage, or worldwide/no location filter.
The subject is active and has its own valid source.
The subject identity field is populated on incoming records.
Connected App sources are bound to a saved Integration workflow.
The record has coordinates or a workflow that resolves coordinates.
Rule condition field names match normalized record fields.
Dwell rules have a positive dwell threshold.
Notification destinations are configured separately if dispatch is enabled.

Common operating patterns

PatternSubjectTypical subject sourceZone source / rule
Shipment arrivalShipment / vehicleAPI, carrier feed, workflowDC approach, yard, dock; entry/dwell/exit
Retail loyaltyCustomer/memberCRM + consented mobile positionStore zone; entry + business eligibility
Yard dwellTrailer / assetTelemetry, scanner, integrationYard/staging; dwell threshold
Field check-inEmployee / field workerMobile/deviceJobsite/service area; entry/exit

Fixed geofence trial

The public trial is intentionally simpler than full DataSynch geofencing. It uses fixed 50m, 250m, or 1000m circles and a consented participant/mobile flow so someone can quickly create a real saved geofence and observe entry/exit behavior. A trial geofence can later be opened in DataSynch and persisted into the normal geofence store.

Using a phone as the homebase

A phone can provide a current or last-known operating point for a temporary field/demo workflow. The location remains subject to the participant’s consent, pause/revoke state, and freshness.

Scaling beyond the trial

Full DataSynch programs can combine many saved zones, master data, Integration workflows, mobile/device telemetry, and downstream notification rules.

Troubleshooting

No event is created

Confirm the program and subject are active, the zone is assigned, the identity field is populated, and the incoming record actually crosses or dwells in the zone.

Connected source does nothing

Confirm a saved Integration workflow is selected and that records from that workflow are actually running through DataSynch.

Master Table source has no fields

Import or add rows to the selected Master Table, then reopen/refresh the source binding.

Location does not match

Check latitude/longitude, address/geocoding output, and whether the record is using current or stale/last-known coordinates.

Rule condition never matches

Verify the field name exists on the normalized record and that the operator/value use the normalized value.

Notification is not delivered

The geofence event may still be valid. Check notification rules/connectors and delivery logs separately.

How to stop sharing

Turn off browser/app location permission, use the revoke link from your invite flow, or contact Atlasemoji support. A saved manifest can remain visible while live location sharing is paused, stale, or revoked.