Ask the Community - Recent Threads

RE: Search API returns an empty response inside a batch request in Verint V14

Patrick M. — Mon, 05 Oct 2026 21:48:42 GMT

I added it under the Api/Extensibility feature changes in the notes. This is is still a backwards compatibility issue that I have filed below.

Search API returns an empty response inside a batch request in Verint V14

John Reynolds — Mon, 05 Oct 2026 15:16:55 GMT

We're investigating a difference in behavior between Verint Community V13 and V14, maybe Patrick M.

Our widget refreshes references to Verint content when the configuration panel opens. For each stored Content ID, it retrieves the current title and URL through the Search REST API. To avoid making multiple individual HTTP requests, these API calls are executed using jQuery.telligent.evolution.batch().

During our V14 upgrade, we did not change the widget code. The same configuration, including the original Content IDs, was copied from V13 to V14.

In V13, the batch response contains the expected SearchResult.

In V14, the request within the batch returns an HTTP status of 200, but its BatchResponse contains only:

{
    message: ''
}

The expected SearchResult is missing.

The content itself still exists in V14. When the same Search API request is made directly, without jQuery.telligent.evolution.batch(), the API returns the correct content data.

Batch request

The following example demonstrates the issue:

var contentId = 'CONTENT_ID';

var baseUrl = jQuery.telligent.evolution.site.getBaseUrl();

var request = jQuery.telligent.evolution.batch(function() {

jQuery.telligent.evolution.get({

url: baseUrl + 'api.ashx/v2/search/{id}.json',

data: {

id: contentId

}

});

request.then(

function(batch) {

var response = batch.BatchResponses[0];

console.log('Status:', response.StatusCode);

console.log('BatchResponse:', response.BatchResponse);

console.log( 'BatchResponse JSON:', JSON.stringify(response.BatchResponse) ); },

function(error) {

console.error('Batch request failed:', error); }

);

Observed result in V13

  StatusCode: 200,

  BatchResponse: {

     SearchResult: {

        Id: 'CONTENT_ID',

        Title: 'Example content',

        Url: '/example-content/',
            ContentType: 'group'
        },

     Info: [],

     Warnings: [],

     Errors: []

}

Observed result in V14

    StatusCode: 200,

    BatchResponse: {

     message: ''

}

}

Direct request in V14

When the same endpoint is called outside the batch request, it returns the expected result:

var contentId = 'CONTENT_ID';

var baseUrl = jQuery.telligent.evolution.site.getBaseUrl();

jQuery.telligent.evolution.get({

  url: baseUrl + 'api.ashx/v2/search/{id}.json',

  data: {

    id: contentId

}).then(

  function(result) {

     console.log('Direct response:', result);

},

  function(error) {

    console.error('Direct request failed:', error);

);

The direct response contains the expected SearchResult, including the correct Content ID, title, URL, and content type.

Questions

Is this a known change or regression in the batch request implementation in Verint Community V14?
Is the Search REST API supported inside jQuery.telligent.evolution.batch() in V14?
If this behavior is expected, what is the recommended approach in V14 for retrieving multiple referenced content items in a single request?

Based on our testing, the issue does not appear to be related to the V13 to V14 migration itself. The content and the original Content IDs are present in V14. The difference in behavior occurs specifically when the Search API request is executed inside a batch in V14

RE: Search API returns an empty response inside a batch request in Verint V14

Patrick M. — Mon, 05 Oct 2026 19:43:36 GMT

Filed and tracked internally as TE-20051

RE: Search API returns an empty response inside a batch request in Verint V14

Patrick M. — Mon, 05 Oct 2026 19:38:37 GMT

The .ashx extension is obsolete in 14, though it's supposed to be backwards compatible, which it is on standard calls. That being said if you ar making changes to begin with you should make the switch.

If it did not work in batch that is something we need to look at and I will file it. The releases notes are still being finalized, I will add this

RE: Search API returns an empty response inside a batch request in Verint V14

John Reynolds — Mon, 05 Oct 2026 19:05:52 GMT

The root cause has been confirmed.

In V14, the batch request works correctly with the new route:

/api/v2/search/{id}.json

Both existing content items were successfully retrieved:

Partners: 200, found: true
BizDev: 200, found: true

Therefore, the issue is not caused by the Search API, jQuery.telligent.evolution.batch(), or the content migration.

The exact technical cause is:

The widget continues to use the legacy V13 route, /api.ashx/v2/.... In V14, direct requests to this route still work for backward compatibility, but requests made through batch() return an empty { message: '' } object. The new /api/v2/... route works correctly inside a batch request.

The primary fix is now much simpler:

// V13
baseUrl + 'api.ashx/v2/search/{id}.json'
// V14
baseUrl + 'api/v2/search/{id}.json'

I would still keep the defensive part of the proposed solution: the widget should not remove a menu item and its child items when the API returns an empty or invalid response. This will prevent configuration data loss if a similar API failure occurs in the future.

The previously proposed internal endpoint based on core_v2_content.Get() is no longer required to fix this issue. The solution will most likely be limited to:

Switching to /api/v2/.
Adding safe handling for empty or invalid API responses.
Verifying whether the new route is compatible with V13 before selecting a single URL for both versions.

RE: Search API returns an empty response inside a batch request in Verint V14

John Reynolds — Mon, 05 Oct 2026 18:58:21 GMT

Yes, we're checking as we write this.

Patrick M. , I don't see this change listed in the release notes. Is it documented somewhere?

RE: Search API returns an empty response inside a batch request in Verint V14

Sara Collins — Mon, 05 Oct 2026 18:56:06 GMT

Patrick M. I can confirm with John Reynolds and team

RE: Search API returns an empty response inside a batch request in Verint V14

Patrick M. — Mon, 05 Oct 2026 18:43:57 GMT

Do the results change if you remove the .ashx from the search url?

RE: Verint Community v13 to v14 upgradation queries.

Patrick M. — Fri, 11 Sep 2026 15:36:33 GMT

I answered a lot of this in your other thread We are planning to migrate from v13 to v14. .

As for custom development this also covered in documentation:

Developing a Plugin

Verint Community v13 to v14 upgradation queries.

Anshuman Prusty — Fri, 11 Sep 2026 09:46:27 GMT

Hi team,

Continuation of the title, We are planning to migrate from v13 to v14. Can you help with the following queries?

S3 Storage Option
Can we use Amazon S3 instead of the app/cfs file system for both the Web and Job containers?
- If yes, could you please confirm the expected effort and key changes required to implement this?
- If S3 is not a supported option, please provide the reason and any technical limitations or dependencies that require the use of the app/cfs file system.
Downloading Container Images
I can see that the container images are referenced in the compose.yml file for the following services. Could you please advise how we can access and download/pull these images?
- Web: af1.verintconnect.com/dfe-community/community/web:14.0.0.644
- Job: af1.verintconnect.com/dfe-community/community/job:14.0.0.644
- Search: af1.verintconnect.com/dfe-community/community/search:14.0.0.619
- Infra: af1.verintconnect.com/dfe-community/community/infra:14.0.0.644
- Installer: af1.verintconnect.com/dfe-community/community/installer:14.0.0.644

Specifically, please let us know the required registry access, authentication method, and the commands or process to pull these images.

3. Can we add our customized code to the images? For example, we plan to use our own TR Coveo search SaaS service instead of the Solr container. We hope to include this in the web container by customizing it; can Verint help with this? Alternatively, is it mentioned anywhere in the document how to customize the images based on our requirements?

4. If the installer container is only responsible for database upgrades, creating community databases, and setting permissions, we plan to use AWS RDS SQL Server and GitHub Actions for our CI/CD pipeline instead. Therefore, we should not need the installer container, correct?

5. how to integrate custom dlls like OAuth Module in V14 version. Could you please provide the steps/documentation.

Thanks in advance for your support.

We are planning to migrate from v13 to v14.

Anshuman Prusty — Tue, 08 Sep 2026 12:19:21 GMT

Can v14 run without containers, i.e. Can v14 be installed directly on AWS EC2 instances?
Can we use Amazon RDS SQL Server or PostgreSQL instead of the SQL pod?
What is the purpose of these paths? And, What type of files will be stored in these locations?
/app/cfs
/var/solr
Will Verint provide images for all services?
Web
Job
Search
Infra
Installer

RE: We are planning to migrate from v13 to v14.

Patrick M. — Fri, 11 Sep 2026 15:32:52 GMT

Are you familiar with how docker and docker compose work? The images are stored in a container repository, they would be pulled if they are not already in your local cash when you run the compose stack.

We are currently only supporting localized development environments, not secondary or on-premise installations. While S3 will be an option for file storage it is out of scope for this current state of 14.

RE: We are planning to migrate from v13 to v14.

Anshuman Prusty — Wed, 09 Sep 2026 12:35:10 GMT

Hi Patrick M. -

Thank you for your response. I have a couple of additional queries:

S3 Storage Option
Can we use Amazon S3 instead of the app/cfs file system for both the Web and Job containers?
- If yes, could you please confirm the expected effort and key changes required to implement this?
- If S3 is not a supported option, please provide the reason and any technical limitations or dependencies that require the use of the app/cfs file system.
Downloading Container Images
I can see that the container images are referenced in the compose.yml file for the following services. Could you please advise how we can access and download/pull these images?
- Web: af1.verintconnect.com/dfe-community/community/web:14.0.0.644
- Job: af1.verintconnect.com/dfe-community/community/job:14.0.0.644
- Search: af1.verintconnect.com/dfe-community/community/search:14.0.0.619
- Infra: af1.verintconnect.com/dfe-community/community/infra:14.0.0.644
- Installer: af1.verintconnect.com/dfe-community/community/installer:14.0.0.644

Specifically, please let us know the required registry access, authentication method, and the commands or process to pull these images.

Thanks in advance for your support.

RE: We are planning to migrate from v13 to v14.

Patrick M. — Tue, 08 Sep 2026 17:08:41 GMT

You can access the installation documents and descriptions here: https://community.telligent.com/community/14/a/user-documentation/c/installation

Community 14 only ships containerized, the container host is at your discretion with docker being the most common. The link above lists all the service containers and how to install.

Community does not support Postgres, you can use SQL Server RDS if you choose.

You can install on an EC2 instance using docker or another containerization environment, but given its containers you may look at options specifically designed to host containers.

The app/cfs is how the application sees CFS in the container, solr the same concept.

Running 14 requires a functional knowledge of running containerized applications to be able to deploy the site and bind mounts, etc.

RE: We are planning to migrate from v13 to v14.

Rich Mercer @ 4 Roads — Tue, 08 Sep 2026 12:30:27 GMT

Hi, v14 cannot run without containers, but it is possible to run it in an EC2 instance. In that scenario, you would need to install docker either in Windows or Linux depending on your EC2 instance (but I would recommend Linux for this), then you can spin the docker stack up in docker compose. Each of those services you listed are available via the container registry and you can spin these up using the example in the v14 docs.

/app/cfs is the file store location and /var/solr would be a search location.

We've been working on upgrading a couple of sites already. 🙂

RE: Revert to default on Group header seems not to stick

Patrick M. — Fri, 14 Aug 2026 15:53:49 GMT

Its designed to be explicit, a choice must be made in order to avoid users not realizing they undid a significant amount of work unintentionally because boxes were checked for them

Revert to default on Group header seems not to stick

Robert Nash — Wed, 12 Aug 2026 14:45:58 GMT

As per title.

Create a group, customize header banner publish

Edit the group theme and revert the banner

Publish changes.... nothing changes

RE: Revert to default on Group header seems not to stick

Robert Nash — Fri, 14 Aug 2026 13:18:10 GMT

very confusing to an end user, or maybe it's just me.

RE: Revert to default on Group header seems not to stick

Faisal Soesatyo — Fri, 14 Aug 2026 13:16:19 GMT

The checkboxes allow users to select which specific header customizations they want to revert. The selected items are reverted when the changes are published, rather than immediately when the checkboxes are selected.

RE: Revert to default on Group header seems not to stick

Robert Nash — Fri, 14 Aug 2026 12:34:17 GMT

You are right that does look like a similar issue. The problem here is one of expectations about what a "revert to default" should do. As an end user if I revert the entire header to default then it should do exactly that and implicitly those checkbox actions should not be required. Speaking of which why are they checkboxes when as far as I can see they behave like buttons, it's not entirely clear when they are applied?

RE: Revert to default on Group header seems not to stick

Faisal Soesatyo — Fri, 14 Aug 2026 12:13:26 GMT

Your issue looks similar to https://community.telligent.com/community/11/f/ask-the-community/1149562/group-banner-widget-s-navigation-items-are-not-affect-by-page-header-revert

The header selection doesn't automatically include every customization beneath it. If you're already selected Navigation item, for example, and it still didn't revert after publishing, it may be new issue. Could you please share the repro steps, along with the expected and actual behavior?

RE: Revert to default on Group header seems not to stick

Robert Nash — Fri, 14 Aug 2026 11:17:31 GMT

I was customizing widgets on the page header, if I edit the group navigation for example, publish and then try and revert the reversion fails, if I click revert to default on the entire header I should not have to manually revert every checkbox in that list.

RE: Revert to default on Group header seems not to stick

Faisal Soesatyo — Fri, 14 Aug 2026 11:14:09 GMT

Hi Robert,

I wasn't able to repro this issue locally. Please make sure you have ticked the option you expect to be reverted. So, it's not only the portion of the page, but also the specific options you want to revert.

RE: What is preventing the menu from displaying the ticket application link

Robert Nash — Wed, 12 Aug 2026 16:38:57 GMT

Finally found the cause if the property Url of CustomNavigationItem is empty then the navigation does not display, which makes sense, however there are no errors or warnings raised to indicate there is an issue.

What is preventing the menu from displaying the ticket application link

Robert Nash — Fri, 24 Jul 2026 12:46:05 GMT

This group has a ticket application; it appears in the app list if I click new I can add a new ticket, but the group menu is not adding it to the display list, have I missed an interface implementation to support this, worked in V13?