🔍 Search profiles (search criteria) with propform

Search profiles are a separate module in onOffice: a buyer/tenant describes their ideal property (region, property type, price range, floor area, etc.), and onOffice later automatically matches them with suitable properties. propform can create complete search profiles via a form — including multi-region, range fields and automatic linking to the address.


Contents


Concept: Search profile ≠ Address field

In onOffice, a search profile is a standalone data record — linked to an address, but not a field within the address. An address can have multiple search profiles (e.g. “Search for a flat in Berlin” + “Search for an investment apartment block across Germany”).

Implications for propform:

  • In the form editor, select search criteria fields as a separate module selection
  • The values are written to the search profile, not to the address
  • propform automatically links the search profile to the address edited/created by the form

Search criteria fields in the form

Setup:

  1. New form → Add address data fields for the enquirer (first name, surname, email, telephone)
  2. For the search: Select the “Search Criteria” module” → Add fields

Typical search criteria fields:

  • objektart (Flat / House / Plot / Commercial)
  • vermarktungsart (Purchase / Rent / Lease)
  • kaufpreis (Range field — propform automatically displays two input fields “from” / “to”)
  • kaltmiete (Range field)
  • wohnflaeche (Range field)
  • anzahl_zimmer (Range field)
  • regionaler_zusatz (Multi-select regions)
  • Plus all custom search criteria fields created in onOffice

> 💡 Range fields: The fields above are simply named kaufpreis, wohnflaeche etc. — not kaufpreis_von / kaufpreis_bis. propform automatically recognises that this is a range field and displays two input fields.

> ⚠️ Important: For a field to appear in the search criteria module, it must be explicitly defined as a search criteria field in onOffice (Tools → Settings → Administration → Search Criteria module). Otherwise, propform will not display it.

---

Range fields (from/to ranges)

Search criteria typically work with range values (price from 200,000 to 500,000, floor space 80 to 120 m²). Simply add the field using its base name (e.g. kaufpreis) — propform automatically recognises that it is a range field and displays two input fields (“from” / “to”).

> ⚠️ Range sliders do not work here: The special “Range Slider” field is only available for standard numeric fields, not for search criteria range fields. For search criteria, there are still two input fields.

---

Multiple selection: Regions & property types

With classic search criteria fields such as regionaler_zusatz or objektart, users often want to tick multiple values (e.g. “Berlin-Mitte AND Berlin-Friedrichshain”). propform does this automatically via the multi-select field.

Tips for multi-select in search criteria:

  • Enable “Dropdown only on input” for fields with many options (regional suffixes often have hundreds) — see Fields → Dropdown behaviour
  • Use parent-child hierarchy: ticking a canton automatically ticks all districts as well
  • Custom labels for multilingual forms (see Multilingual forms)

---

Geographical search: radius vs. regional supplement

In onOffice, there are two fundamentally different ways to set up a geographical search — each has its strengths:

Option A — Radius (address + radius)

The user enters a reference address (postcode, town, street) plus a radius in kilometres. The system matches properties located within this circle.

Advantages:

  • Easy to explain and use — most users think in terms of “Central Station + 10 km”
  • Works globally without the need to pre-configure regions
  • Less setup effort in onOffice

Fields: umkreis_ort, umkreis_plz, umkreis_strasse, umkreis_radius

Option B — Regional add-on (pre-configured regions)

The user selects from a multi-select region hierarchy (federal states → districts → neighbourhoods). This requires that your regions are maintained in onOffice and that the properties have been correctly categorised.

Advantages:

  • Granular control over which regions are available for selection
  • Parent-child hierarchy: clicking on “Bavaria” selects all Bavarian sub-regions with it
  • Consistent reporting analyses (region as a dimension)

Field: regionaler_zusatz (Multi-select)

Recommendation

When Selection
General end-customer form, all locations Radius
Locally operating estate agency with clearly defined districts Regional Supplement
Premium search profiles, relevant for reporting Regional Supplement
Quick setup without onOffice region maintenance Radius

> ⚠️ Switching between variants is not straightforward — Search profiles created using radius cannot be converted 1:1 into regional add-ons (different data type). It is best to decide on a variant at the outset and stick to it consistently.

---

Automatic linking to address

propform automatically links search profiles to the address that the form is currently editing or creating — you do not need any additional data record connection configuration.

Typical workflow:

  1. The enquirer fills in address details + search criteria
  2. propform creates an address record (or finds an existing one via the duplicate check)
  3. propform creates a search profile + automatically links it to this address
  4. Optional: Create an activity referencing the address

> 💡 An address record can have any number of search profiles. If the same enquirer creates multiple searches, a new search profile is added each time, all linked to the same address.

---

Displaying and outputting search criteria

There are propform-specific macros for confirmation emails or overview displays:

Macro Effect
_pfGetSearchCriteriaInformation Outputs the search profile just created as a complete table (all values)
_pfGetSearchCriteriaField(<feldname>) Outputs a single value — e.g. _pfGetSearchCriteriaField(objektart)
_pfGetSearchCriteriaUUID Encrypted UUID of the search profile — for secure cross-form links
_pfButton(<URL>;<Beschriftung>) Generates a formatted button link in emails/PDFs — accepts any URL including macro-resolved UUIDs (e.g. an edit link to the search profile)

Example confirmation email after submission:

Hallo _Vorname _Name,

vielen Dank für deine Suchanfrage. Wir haben folgendes Suchprofil angelegt:

_pfGetSearchCriteriaInformation

Wir melden uns, sobald passende Immobilien verfügbar sind.

→ The complete table of search criteria is automatically inserted into the body.

📖 More under Macros — propform-specific.


Edit / deactivate search profiles

propform can not only create new search profiles, but also read, edit and deactivate existing ones — perfect for self-service channels (“Manage your search profiles yourself”).

Pattern: Overview email + 1-click actions

Very robust self-service workflow for buyers/tenants:

  1. Overview email (via email template, triggered from onOffice or as a newsletter): lists all active search profiles in a loop (see next section). Two buttons per entry:
    • “Edit” → URL to an edit form with search criterion UUID as a parameter
    • “Deactivate” → URL to a deactivation form with search criterion UUID
  2. Edit form: Standard search criteria form, loads the search profile via UUID, saves changed values.
  3. Deactivation form: Simply sets the status field to 0. With Auto-Submit (see Auto-Submit & Routing) — the user clicks the link in the email and the form is submitted without UI interaction → the thank-you page appears immediately.

Setup requirements

  • Search criterion module fields in the edit form as in the create form
  • Filter per form based on the user’s own address reference (see Filter per form) — prevents users from editing other users’ search profiles via UUID manipulation
  • UUID requirement (see Form protection) — no access without a search criterion UUID
  • In the summary email: use the _bScRek_("status:1") loop (see below) and the _pfGetSearchCriteriaUUID + _pfButton(...) macros for the action buttons

> 💡 Best Practice: The _pfButton macro automatically handles the layout (button styling) — you don’t need to format in HTML.


Search criteria loop for overview emails

If a user has multiple search profiles and you want to list all of them in an email or overview page, use the search criteria loop:

_bScRek_("status:1")
Suche: _pfGetSearchCriteriaField(objektart) in _pfGetSearchCriteriaField(ort)
Preis bis: _pfGetSearchCriteriaField(kaufpreis_bis)
Link: _pfLink("https://example.com?id=_pfGetSearchCriteriaUUID", "Suchprofil öffnen")

_eScRek_

Filter status:1: Only active search profiles. Without filter: all (including deactivated ones).

📖 Full syntax and filter options under Macros → Search Criteria Loop.


## Premium search profiles

In some onOffice versions, there is a dedicated field “Premium search profile” (often prio or a custom field) — a flag for particularly important buyers/tenants who should be notified more quickly or in greater detail about new properties.

propform setup for Premium flag:

  • Add a “Premium” field as a single-select (Yes / No) or Boolean to the search criteria form
  • Set the default value to “Yes” if the form is accessed via a Premium link (URL parameter)
  • Create a filter in onOffice called “Premium search profiles only” → use this to maintain your own email campaign

> 💡 If you don’t have a Premium concept yourself, this isn’t necessary — the standard search profile workflow will suffice.

---

Pitfalls

Search criteria templates (API only reads the default template)

In onOffice, under Tools → Settings → Administration → Search Criteria, you can define several templates — for example, a “Residential Property Buyers” template, a “Commercial Tenants” template, etc.

> ⚠️ Pitfall: The onOffice API reads only the default template. Alternative templates are completely ignored.

Symptom: You add a new search criteria field in an alternative template, but propform cannot “find” it. Frustrating.

Solution:

  • Always maintain fields you wish to use in propform forms within the default template
  • Or switch to the default template (if you have deliberately structured it differently)

Object Type vs. Object Class — Incompatibility

If the form writes both objektart and objekttyp, the values must be compatible. Incompatible combinations (e.g. Object type = Wohnung + Object class = Mehrfamilienhaus) result in the search criterion not being created silently — no error message, no record.

Tip: When designing the form, test the value logic with different combinations before rolling it out.

Address must exist before search criterion

The search profile is always linked to an address. If your form creates a new search profile but the address does not yet exist (duplicate check fails, new address is created), the address creation runs first, then the search profile.

→ This works without issues in most cases. The search profile may only fail in the event of very unusual validation errors on the address.


Related