My form isn’t sending data to onOffice

If a form is submitted but the data doesn’t reach onOffice — or only arrives partially — this is due, in 9 out of 10 cases, to the permissions of the onOffice user that propform is communicating with. Here are the most common causes, listed in order of likelihood:

1. API user permissions are not (fully) set

The API user in onOffice requires appropriate read and write permissions for all modules that your form uses (Addresses, Properties, Activities, Tasks, Appointments, Search Criteria, Templates).

Solution: The full set of recommended permissions is documented here: onOffice API user permissions.

> Take particular care to ensure that read AND write permissions are set to “all” (not “only my own”) if your form is intended to edit records belonging to other staff members.

2. Address has the “Private” checkbox ticked

If an employee in onOffice ticks the “Private” box for an address record, no one except the user who ticked it can read or edit that address anymore — not even the API user.

Symptoms:

• The form reports “Address not found”, even though the UUID is correct
• Certain individual addresses cannot be loaded, whilst others can

Solution:

• Open the relevant address in onOffice
• Remove the ‘Private’ checkbox, or
• Assign the address to the API user

3. Record permissions are restricted

In onOffice, record permissions may be set on individual addresses, properties, templates or template folders that exclude the API user.

Common scenarios:

• A PDF property brochure template is located in a folder with restricted permissions → propform cannot generate the brochure
• An email template has read restrictions → propform cannot use the template for sending emails
• Certain addresses or properties are only visible to a specific user group → propform cannot load them

Solution:

• Check the relevant data record permissions in onOffice (right-click on data record/template/folder → Permissions)
• Add the API user (or their group) to the permissions list

> ⚠️ Common oversight with templates: There are three permission levels for email/PDF templates: > 1. The template itself (spanner icon on the template → record permissions) > 2. The template folder containing the template (wrench icon on the folder!) ← often forgotten > 3. The API user under the ‘Permissions’ tab → ‘Word, Email Templates, Files’ section → ‘Read Templates → All’ > > If the template does not appear in the drop-down selection in propform, check all three levels.

4. API user is not assigned to a group (Groups module active)

If your onOffice system uses the Groups module, by default a user will only see records that belong to their groups. If the API user is not assigned to any group, they will see correspondingly little.

Solution: Assign the API user to a group with the most comprehensive read permissions possible.

Here’s how to do this in onOffice:

1. Click on Tools → Settings → Users in the menu bar
2. Select the API user
3. Switch to the “Groups” tab
4. Add the user to a group that has maximum read access (or create a separate “API Users” group if necessary)

> If you are unsure which group is the correct one, ask your onOffice administrator or onOffice Support.

5. Field not activated in onOffice

If a specific field in your form is not transferring any data, check in the onOffice Administration whether the field is activated there at all. Inactive fields are not offered to propform — and if you have copied it via migration, the value disappears into thin air.

Special case: search criteria: Fields must be explicitly defined as search criteria fields in the onOffice Administration, otherwise they will not be offered to propform in the search criteria module.

6. Error message “onOffice resource could not be read or found”

This typical API error message appears when propform attempts to load a record from onOffice but cannot find a matching one.

Common causes:

• Incorrect or outdated UUID — the record has been deleted in onOffice or the UUID is no longer valid (e.g. because a record was recreated via migration)
• Restricted API permissions — the API user is not authorised to view the record (see points 1–4 above)
• Module not activated — e.g. the Search Criteria or Tasks module is not enabled at all in the onOffice account

Procedure for narrowing down the issue:

1. Manually enter the UUID into the onOffice search — is a record displayed?
2. If so: Log in with the API user and check whether they can see the record
3. If the API user cannot see it → Permissions/group issue (see above)

> If you cannot find the cause, send us an email with the UUID, the form and the error time — we will look at the logs together.

7. Form has too many fields → onOffice API returns NULL

With very large forms (many fields, especially complex custom fields), it can happen that the onOffice API no longer returns any record at all — not just one field is missing, but the entire API call returns NULL.

Symptoms:

• The form appears not to be loading any data at all (all fields are empty, even those that definitely contain data)
• The issue disappears when certain fields are removed from the form

Background: This is a limit on the part of onOffice/MariaDB — if there are too many or too complex fields (particularly long texts, many multi-select fields), the API response breaks down. Cannot be resolved on the propform side — we have discussed this with onOffice on several occasions.

Workaround:

1. Gradually reduce the size of the form until the dataset loads again
2. Identify the field causing the issue and, if necessary, move it to a separate follow-up form
3. For custom fields with long texts, check whether the content absolutely needs to be read

8. Marketplace users without API permission configuration

If you have activated propform.io via the onOffice Marketplace, propform runs with a special Marketplace token, not with a standard API user. You usually cannot fine-tune the permissions yourself here — they are predefined by the Marketplace configuration.

If you require very granular permission control, switch to a standard API user with its own token and secret. Instructions: Create API user.

9. The “Only properties published on the website” trap for API users

In the API user permissions tab under Properties, there is a specific tick box labelled “Can only read properties published on the website”.

> ⚠️ This setting overrides the general “Read properties → all” permission. Even if you have selected “all” above, the API user with this restriction active will only see the properties that are active on a website — all others are invisible, as if they did not exist.

Symptoms:

• Certain properties cannot be found in propform forms, even though the UUID is correct
• PDF property description generation fails silently (API returns NULL)
• Workflows only work for “active” properties, not for internal / archived / unpublished ones; ; Solution: Uncheck the box if you want propform to work for all properties (including internal valuation/acquisition objects).; ;

10. PDF has been created but is not visible in the “Files” tab of the record

After submission, the PDF is created asynchronously in the background — typical delay 10–30 seconds. If the PDF still does not appear in the “Files” tab of the address or property:

Common cause: File filter in the “Files” tab is active.

In the onOffice interface, a default filter is often preset in the “Files” tab (e.g. “images only”, “energy performance certificates only”, “own tab only”). The newly created PDF may not meet the filter criteria and is hidden, even though it is there.

Solution:

• In the “Files” tab at the top, reset the filter to “All files”
• Or manually set the filter to the document attribute of the propform PDF

> 💡 If the PDF is still not there after resetting the filter: wait a few seconds, then press F5. If it is still missing → check API permissions (point 1) and record permissions (point 3).

If nothing helps

Send us an email to hello@propform.io with:

• the form URL,
• the date & time of the failed submission,
• a brief description of what happened and what didn’t.

We’ll then look at the logs together with you.