Feasibility

Part of the IP4CMS portal. ← All module guides

What it's for — the Feasibility module answers a single practical question: can a service be delivered at a given location (or for a given resource)? It checks a set of coordinates against your configured rules — how close it is to existing infrastructure (proximity), whether it falls inside a coverage area (polygon), whether there is a clear line of sight to a tower, whether a bookable resource is free in a date/time window (availability), and whether an external network operator reports the address as serviceable (external API). You point it at a location, it runs the checks, and it returns Feasible (Yes), Not feasible (No), Maybe, or Pending — together with which products or resources are available there.

Where to find it — Feasibility lives in two places in the portal:

• Feasibility Requests (under the main menu) — where operators run checks and review results day to day.
• Settings → Feasibility — where the building blocks are configured: layers, queries, resources, resource types, and external providers. Each request form also has a "Set up feasibility configuration" link that jumps you here.

Before you start

• Licence module. Your tenant's licence must include the feasibilities module. Some capabilities sit behind sub-modules: request groups need feasibilities:request_groups (the Mapping module also unlocks these), OpenServe Fibre needs feasibilities:openserve, and Telkom LTE needs feasibilities:telkom_lte. If a sub-module isn't licensed, that provider or screen simply won't be available.
• Permissions. You need to be a signed-in portal user. All feasibility screens require authentication; running a check is also available to the customer-facing portal via API key, so the same configuration powers both internal and self-service checks.
• Configuration first. A request can only run against active layers. If no layers exist yet, build them in Settings before running checks (see Key tasks below).

Key tasks

Run a feasibility request

This is the core operator task — checking one location.

1. Go to Feasibility Requests and click New Request.
2. Optionally enter a Description (e.g. "Site A check for new tower") to help you find it later.
3. Select layers — tick one or more active layers. The request runs every query in those layers. The overall result is Feasible if any selected layer comes back feasible.
4. Resource Types (optional) — tick one or more types (product, package, inventory, user, supplier) to limit which resources are evaluated. Leave empty to check all.
5. Coordinates (optional) — click on the map to drop a marker, drag it to fine-tune, or type Latitude and Longitude directly. Coordinates are required for proximity, polygon, line-of-sight, and the external providers.
6. Resource / Date-Time (optional) — for availability checks, enter a Resource ID and a From/To window with a Timezone.
7. Click Execute Request. Results appear in the list with a Processing status (Pending / Processing / Completed / Failed) and a Feasibility result (Yes / No / Maybe / Pending). Click View on any row to see the per-layer and per-query breakdown, including matched resources and the raw details each query returned.

A result is Maybe when some queries pass and none clearly succeed, and Pending when an external generic-API query is still waiting on its callback.

Work with request groups

When many locations are checked together (for example, a bulk upload from the Mapping module), the individual requests are gathered into a request group.

• Open a group to see headline stats — Total, Pending, Processing, Completed, Failed — and a Feasibility result summary (Feasible / Not feasible / Maybe / Pending, each with a percentage).
• The group lists every request inside it; click View to drill into one.
• Click Export to CSV to download all requests in the group with their coordinates, status, preferred layer, preferred query, and description. (Request-group screens require the feasibilities:request_groups or mapping licence module.)

Manage layers

A layer is a named bundle of checks — think of it as one "answer path", e.g. Fibre Coverage or LTE Coverage. A request can run several layers at once.

In Settings → Feasibility, create a layer with:

• Key (a short stable code you reference elsewhere), Name, Description, and an Active toggle.

Then attach queries to the layer and set their sort order (priority). Within a layer, the first query to return Yes becomes the preferred query, and that layer becomes the preferred layer for the request — useful for picking the best product to offer. Only active layers and active layer-query links are evaluated.

Build and run a query

A query is one individual check. Create it with a Key, Name, and a Type, then fill in the type-specific settings:

• proximity — Max Distance (m) (default 1000). Passes when the location is within that distance of at least one of the query's linked locations.
• inside_polygon — passes when the location falls inside the shape of at least one linked location.
• line_of_sight — Radius (m), Min Clearance (m), and Samples (default 128). Passes when there is an unobstructed sight line (terrain elevation is sampled along the path).
• availability — Resource Type. Passes when the resource is free in the requested window.
• external_api — URL, Method (POST/GET/…), and Timeout (ms); or pick a named provider (see below).

Queries also carry an optional colour (for map display) and an Active toggle. Mark a query inactive to exclude it without deleting it. You can run a check directly from the New Request form, or pre-build queries here and attach them to layers.

Use external provider integrations

For real-world network feasibility, queries of type external_api can call an operator's API instead of using your own data:

• Generic (async) — any custom external API. You configure the URL and method; the result comes back later via callback, so the query sits at Pending until the operator responds.
• OpenServe Fibre — South African FTTH (fibre) feasibility. Synchronous: it checks the address immediately and returns Yes when fibre status is Working and products are available. Requires the feasibilities:openserve sub-module.
• Telkom LTE — South African LTE coverage. Synchronous. Requires the feasibilities:telkom_lte sub-module.

The portal only offers the providers your licence enables, and access is re-checked every time a query runs. Each provider needs valid coordinates; OpenServe and Telkom also need an API key (configured per query or via environment).

Manage resource availability

For availability checks you maintain availability windows for your resources (products, packages, inventory, users, suppliers):

• View, create, edit, and delete availability records, filtered by resource type, resource ID, a From/To range, and an is-available flag.
• Use Check availability to test a single resource at a specific moment.
• Each resource also has a config: feasibility type (date or time), time interval (minutes, for time-based booking), and an optional cooldown period (days for date-based, minutes for time-based) that blocks the resource for a buffer after a booking ends. Resource types and the module-to-resource-type mapping let you label and group resources so the right ones are evaluated for each request.

How the data connects

Locations & mapping. Proximity, polygon, and line-of-sight queries test the request's coordinates against Locations from the Locations module. A query can pull its locations three ways, combined: specific linked locations, every location in a location group, or a location filter (by type, status, group, supplier, or name match). The module keeps these resolved into a fast lookup table automatically, and exposes location geometry so feasibility coverage can be drawn on the Mapping module's maps. Bulk feasibility runs initiated from Mapping create the request groups described above.

Resources. Availability queries link to feasibility resources, which are pointers to real entities elsewhere in the portal — products and packages (from Sales & Orders), inventory, users, and suppliers. When a request is feasible, the module records the matched resources for each layer, so the result tells you not just whether service is possible but what you can offer. A feasible request can flow onward into an order (the portal can create an order directly from a feasibility request).

Layers, queries, locations, resources therefore form a chain: a request runs one or more layers → each layer runs its queries → each query tests coordinates against locations or a resource's availability (or an external operator) → the result rolls up to a per-layer status and an overall Yes/No/Maybe/Pending, with preferred layer/query and matched resources attached.

Permissions & access

• Module licence — feasibilities must be enabled for your tenant. Request groups additionally require feasibilities:request_groups (or mapping); the OpenServe and Telkom providers require their own sub-modules.
• Authentication — every feasibility screen requires a signed-in portal user. The execute and availability check endpoints additionally accept an API key, which is how the customer self-service portal runs the same checks.
• Visibility — because the portal only shows licensed modules and menu labels can be renamed per deployment, the Feasibility menu item may appear under a different name or be hidden if the licence doesn't include it.
• Data scope — all feasibility data (layers, queries, requests, resources) is scoped to your tenant; you only ever see and act on your own organisation's records.

Tips & gotchas

• No active layers, no result. A request only evaluates layers that are marked Active and selected on the form. If a check returns immediately as Not feasible, confirm the layer is active and actually has active queries linked.
• Overall is "any", layer is "first yes". The request is Feasible if any selected layer is feasible, and inside a layer the first Yes (by sort order) wins as the preferred query. Order your queries deliberately if you use the preferred-product behaviour.
• Coordinates are mandatory for location and external checks. Proximity, polygon, line-of-sight, OpenServe, and Telkom all need a valid latitude/longitude. Without coordinates these queries return No with a "missing coordinates" note.
• Generic external API is asynchronous. A generic external query stays Pending until the third party calls back. The OpenServe and Telkom providers answer immediately.
• Provider access is licence-gated at run time. Even if a query is configured for OpenServe or Telkom, it will fail at execution if the matching sub-module isn't licensed — and you also need the provider's API key configured.
• Inactive vs deleted. Toggle a layer or query inactive to take it out of evaluation without losing its configuration; only delete when you're sure it's no longer needed.
• Cooldown blocks the buffer, not just the booking. When an availability resource has a cooldown, the resource is treated as unavailable for the cooldown window after a booking, so a request inside that buffer will come back Not feasible.
• Use Export to CSV for reporting. The request-group CSV is the quickest way to hand a batch of results (with coordinates and preferred products) to colleagues or import them elsewhere.