[REWST - TASK] PSA-Halo: List Company Locations
This workflow pulls all client location data from HaloPSA, making it a handy building block for automations that need accurate site info. It uses a simple API call to fetch and format location details, so other workflows can use them for things like dispatching techs, onboarding, asset tracking, or location-specific monitoring. MSPs can plug it in wherever up-to-date location data is key to managing tickets or making operational decisions.
This workflow contains 5 tasks.
Inputs
psa_location_id - string
If known, we pass a specific ID into the sub which will return the details specifically for that location rather than returning all locations
Outputs
automation_log: Standardized Rewst automation log
locations: A list of locations for the organization that the workflow was run for.
location_lookup_details: Location details are returned if a specific ID was provided to the workflow via the
psa_location_id
field.
Key tasks
set_output_var: Core integration: noop
halo_list_sites: HaloPSA integration: List Sites
Jinja examples
Example 1
This expression creates a sorted dropdown-friendly list of company locations by transforming site data into an ID/label format that works well with form elements. It accesses the CTX.company_locations.sites
data and extracts just the ID and name fields, sorting them alphabetically by name for easier selection. MSPs can modify this expression to change the sorting order (e.g., sort(attribute='id')
for ID-based sorting) or add additional fields like \"region\": sites.region
to provide more context in selection menus. For example, you might customize it to filter only active sites: [{\"id\": sites.id, \"label\": sites.name} for sites in CTX.company_locations.sites if sites.status == \"active\"]
.
Example 2
This expression extracts comprehensive location information by finding and formatting details about a specific company location that matches the PSA location ID. It accesses multiple properties from the matching location object, including address components and company details, using the |d
default filter to handle missing values gracefully. MSPs can customize this by changing the filter condition (e.g., matching by name instead of ID) or modifying the structure to include additional fields like "country": location.country|d
or "phone": location.phone|d
that might be relevant to their documentation or integration needs.
Last updated
Was this helpful?