Odyssee Field Service

Odyssee Field Service, also branded Wello Field Service, is built for companies that install, service and maintain equipment, and the thing that separates that business from generic ticketing is the installation. A job is not work done for a customer, it is work done to a machine at an address, and the machine has a history that outlives every technician who has touched it. Odyssee models that as a project, and the API enforces it: a job created without a project_id, or a matching reference_back_office, is rejected with HTTP 422 and a descriptive message, because a job must reference an installation. That single validation rule is the best thing about this connector, and it is worth building flows around rather than working around.

The API is a stateless OData v4 REST service, and list operations support server side filtering, ordering, column selection and paging, so flows scope large data sets at the vendor rather than in the flow. Companies and contacts are the customer side, fully writable through List Companies, Get Company, Create Company, Update Company and the matching contact actions. Work orders are the job, through List Work Orders, Get Work Order, Create Work Order and Update Work Order, with tasks sitting underneath them through List Tasks, Get Task, Create Task and Update Task. Projects, the installations and assets, are writable through List Projects, Get Project, Create Project and Update Project. Meetings are bookable against a project through List Meetings and Create Meeting. Two areas are read only and it is worth saying so directly rather than implying otherwise: articles, the products and parts catalog, are available through List Articles and Get Article only, with no create or update, and purchasing is available through List Purchase Orders and List Purchase Order Details only, with no way to raise or amend a purchase order from here. Users are read only too, through List Users and Get User, which is the right shape for resolving a technician rather than managing a roster.

Two behaviours change how you design. There is no delete: the REST API exposes no DELETE verb for the top level entities this connector covers, and companies in particular cannot be deleted at all. To take a record out of active lists you update it with archived: true through the Additional Fields object, where the entity supports it. And statuses, types and priorities are not fixed enums. Job status, job type, job priority, task status and project status are GUID foreign keys into per tenant lookup tables, so this connector ships no hardcoded value dropdowns and instead reads those lookup tables live, which means a status is always a GUID resolved from the account it is being written to. Create and update semantics are conventional: creates POST to the collection, updates PUT to /Entity(id) using the OData key syntax with a GUID, and an update sends only the fields you provide. Every documented field the typed parameters do not cover, including the many udf1..N user defined fields and the full address blocks, goes through the Additional Fields object.

On events, this connector has no triggers. The Odyssee API publishes no webhook subscription mechanism at all, so real time events are not available, there is no action here that registers one, and nothing creates a FlowRunner trigger. Change detection is a scheduled poll of a list action filtered on the standard modified_dateutc timestamp, for example modified_dateutc gt '2024-01-01T00:00:00.000Z', carrying the last seen timestamp between runs. OData is case sensitive, so operators are lowercase, and, eq, gt. Every list response is paged at 20 items by default, with an @odata.nextLink for the next page and rows under value.