Troubleshooting

Most Universal Search problems come down to a handful of causes: indexing was never started, a permission set is missing, a sandbox blocks the activation request, or one table failed to index. This page lists each symptom with its cause and the fix, roughly in the order they appear during setup.

Universal Search finds nothing

Cause. Indexing has not run. After installation, indexing is off, no job queue entry exists, and the starting rows wait in Pending rebuild.

Fix.

1. Open Universal Search Setup and choose Actions, then Start Indexing.
2. Open Search Index Configuration and choose Actions, then Process Now.
3. Check that the rows show Active and a number in Indexed Records, then search again.

See Start indexing. If only some records are missing, check that their table and field have a row on Search Index Configuration, that a Record Filter does not exclude them, and that the user can read the table.

Searches shorter than two characters always return nothing.

Activation fails in a sandbox

Symptom. The wizard's Result step says: "Could not reach the license service. In sandboxes, enable "Allow HttpClient Requests" for Universal Search on the Extension Management page, then try again. Search keeps working meanwhile."

Cause. Sandboxes block outbound HTTP requests from extensions until you allow them.

Fix. On Extension Management, open the settings for Universal Search and turn on Allow HttpClient Requests, then choose Retry or run the wizard again. See Activate the license.

If the message is "The license service returned an unexpected response. Please try again later.", the service answered but not as expected. Try again later. In every failure case the activation status does not change and search keeps working.

An administrator cannot start indexing

Cause. Start Indexing creates a job queue entry. An administrator who is not a SUPER user needs BAA SEARCH ADM, which grants the job queue permissions.

Fix. Assign BAA SEARCH ADM to the administrator and try again. See Assign permissions and the permission sets reference.

A row shows Error

Cause. Indexing the table failed, for example because a configured field no longer exists on the table. Every row of that table shows Error, and Last Error shows the message, such as "The supplied field number '50100' cannot be found in the 'Customer' table." The other tables keep indexing.

Fix. Correct the cause, select the row, choose Rebuild Selected Table, then Process Now. A table in Error is not rebuilt until you do this. See Monitor indexing.

A result says the record no longer exists

Symptom. Opening a result shows "This record no longer exists. The index will update shortly."

Cause. The record was deleted after it was indexed, and the background job has not yet removed it, or indexing is paused.

Fix. Wait for the next run of the background job, or choose Process Now. If Indexing Enabled is off, deletions are not queued; turn it back on and rebuild the table.

New records in a table do not appear

Cause. The table's row was added after some users had already opened Business Central. Live change tracking for a newly added table starts only in sessions opened after the change, so edits made in sessions that were already open are not queued.

Fix. Ask users to start a new session. Then select a row of that table, choose Rebuild Selected Table and Process Now to index everything that changed in the meantime.

Still stuck

Contact Bitta Apps through the contact page with the text of Last Error, the job queue entry status, and your Business Central version.

What's next

For every grant in the two permission sets, see the permission sets reference.