Ask the Community - Recent Threads

Search Ranking Breakdown

Rachel Jackson — Wed, 08 Jul 2026 15:26:58 GMT

Good Day,

I've seen a few posts on how to prioritize search results by configuring Solr, but is there any information on how it ranks content for priority in the search results?

It looks like Tagging influences the results, and there is the option to populate only content X years old, but are there any other factors that may influence what populates on top and how those are weighted/ calculated? Do things like View Counts, Likes, etc. also impact the prioritization and weight of results populated?

RE: Search Ranking Breakdown

Karl Barber — Wed, 14 Oct 2026 09:27:55 GMT

You also need to consider the setting for matching words as this effects the results returned, and for short queries can work not as you might expect

This is related to the mm value in the solrconfig file
<str name="mm">2<2 3<50% 11<5</str>

2<2 3<50% 11<5

Solr searches the query words across the configured fields, then requires a minimum number of those words to match for a document to qualify.

The rule works out as:

1–2 words: all words must match.
3 words: at least 2 must match.
4–11 words: at least half must match, rounded down. For example, a 6-word query needs 3 matches; an 11-word query needs 5.
12 or more words: at least 5 must match.

So a longer query can still return a document that misses several words, but the minimum eventually levels off at five.

“Match” doesn’t mean the words must appear together as a phrase; phrase settings can boost close matches, but this mm rule is about how many query clauses match.

RE: Can I invite other community members to collaborate on an article?

Sara Collins — Thu, 08 Oct 2026 13:36:43 GMT

Hi Irene van der Zanden

I hope you're doing well, and thank you for tagging me! Here's how I'd approach this on 13.x:

1. Use a "working" article collection to draft, then move the final version
Rather than creating a collection per article (which, as Lisa mentioned, doesn't scale), you can set up just two:

A restricted "working" collection that only the people collaborating on content have permission to create and edit in.
Your open, published collection that the wider group sees.

Authors can create their article in the working collection and either save it as a draft or post it there. Either way it stays tucked away from the broader group while the collaborators review and edit it. Once edits are done, an admin can move the finalized article into the open collection. That way you only need one extra collection and one role, instead of setting up permissions for every article.

The one trade-off is that anyone permissioned to the working collection can work on everything in it. It's not a per-article "invite to collaborate," but for most teams that's a manageable group.

2. Version management is built into Articles
This is where Articles works really well for collaboration. Every article keeps a version history, so as different people make edits you can see how the article has changed over time. You can also compare versions against one another to see exactly what changed, and restore a previous version if something needs to be rolled back. So even with several people working on the same article, nothing gets lost.

3. For Word documents, keep the working copy outside the gallery
Media galleries let you edit a file and replace the uploaded document, but they don't keep a version history, so each upload overwrites the previous one. If the team needs to co-author a Word doc, I'd recommend keeping the working copy in SharePoint/OneDrive (where co-authoring and version history are built in) and linking to it from the group. Then upload only finalized versions to the gallery, with the version or date in the title (e.g., "Strategy Plan v2 – Oct 2026"). Or, if the content doesn't need to stay a Word doc, moving it into an article gives you the version history right in the community!

So in short: draft and edit in a restricted working collection, use article version history to compare and restore changes, then move the final article to the open collection. Keep SharePoint/OneDrive for anything that needs to stay a Word doc.

Can I invite other community members to collaborate on an article?

LisaM — Wed, 22 Jul 2026 13:47:47 GMT

Looking to use the articles app in a private group to provide a way where the group members can post up a strategy plan as an article but invite other specific individuals to also be able to edit the article as well.

I can't see a way of being able to do this for specific articles? Only via 'permissions' but that applies to a whole article collection and not individual ones.

Is there a way of doing this without a massively manual and convoluted work around?

Lisa

RE: Can I invite other community members to collaborate on an article?

Irene van der Zanden — Thu, 08 Oct 2026 12:38:13 GMT

Sara Collins would you have any recommendation for this? Thank you in advance!

RE: Can I invite other community members to collaborate on an article?

Irene van der Zanden — Fri, 18 Sep 2026 13:07:43 GMT

I have a similar question, although I am not looking for working on an article simultaniously or be able to collaborate on an article, mostly on a blog post or uploaded word doc.

I was wondering if - apart from the workaround in articles - there are other options to collaborate on a document or content on the community AND manage versions and the same time. How does version management look if you are working on the same documents/wiki/content at the same time?

Thanks!

RE: Custom Metadata Widget

Sara Collins — Tue, 15 Sep 2026 19:57:26 GMT

Hi Eion Ness !

Wanted to follow up - we were able to reproduce this on our end too. As a reminder, this widget is headless by design - nothing displays visibly on the page itself, it just writes a <meta> tag into the <head> (that's the same behavior another customer describes using this widget for in this public thread).

What we found: the tag shows up fine in View Page Source when logged in, but it's missing entirely when checked as an unauthenticated/logged-out visitor - so this is a real, confirmed gap between authenticated and anonymous rendering, not a one-off testing issue.

We also weren't able to locate this widget anywhere in the backend on our end either. Our best guess: this is an older widget that's been effectively deprecated but never fully removed. The earliest documentation we could find for a "Custom Metadata" widget goes back to Community 8.x, and per Verint's Community 12 release notes, bug TE-17679 (Community 12.1.3) split this kind of functionality into two newer widgets going forward. The one Verint still documents today is "SEO Meta Data for Content Pages". It's likely the original Custom Metadata widget was meant to be phased out in favor of that newer one, but was left selectable in the widget picker without being cleaned up - which would explain why it still works partially, why it's missing from current docs, and why neither of us can find a backend management screen for it.

Given all that, we'd recommend opening a case with Verint Support to confirm whether the anonymous-user behavior is expected or a bug, since it's an out-of-the-box widget and only Verint can speak to its internals.

Thank you!

Custom Metadata Widget

Eion Ness — Tue, 15 Sep 2026 16:21:01 GMT

While attempting to set custom meta information on our home page we have found a widget call "Custom Metadata" which seems to provide partial function. While testing we discovered that the widget doesn't populate for unauthenticated users, but when we went to fix this issue the widget is nowhere to be found anywhere in the backend. How would we go about editing this widget or even just seeing how it functions to create our own version?

Custom Page - Internal Server Error

Ahmed Gasim — Mon, 14 Sep 2026 05:41:01 GMT

Hello,

Me and my team are currently in the process of rolling out a new theme for our community website.

While trying to navigate to the URL's of custom pages created within a different theme we get an error message:

"The page cannot be displayed because an internal server error has occurred."

We are currently testing in the enabled preview environment and every custom test page created is also resulting in the same error.

For a smooth launch of our new community's theme we would ideally want these links to be functional as they currently are on the live site.

Any help or advice would be greatly appreciated!

RE: Custom Page - Internal Server Error

Sara Collins — Mon, 14 Sep 2026 13:15:09 GMT

Hi Ahmed Gasim

Thanks for posting this - I've run into this exact thing with a few clients during theme rollouts, so hopefully I can save you some head-scratching. Quick caveat up front though: this is our best read on what's going on based on how Verint's theme/page system is documented, not something we've got a confirmed fix for from Verint or seen written up elsewhere, so treat it as a strong lead rather than gospel.

Here's the theory: custom pages in Verint live inside whatever theme they were built in, not at the site level. So when you spin up a brand new theme, it doesn't pull those page definitions over from your old one - the new theme just doesn't know those pages exist yet. That would explain why the old URLs blow up with that generic internal server error instead of a normal 404 - there's nothing for it to resolve against.

That same idea would also explain the test pages you're building fresh in preview. Preview mode is really just staging your changes so you can see them, and based on how Verint describes it, a brand new page's URL may not actually be resolvable until you commit and publish it - so even pages you just built could 500 while they're sitting in that "staged" state.

I want to be honest that I haven't been able to confirm this is exactly what's happening under the hood - I checked Verint's public documentation and known issues, and our own internal tracking, and didn't find anyone describing this specific behavior on 13.x. So it's possible there's something else going on. That said, here's what I'd try, since these are safe either way:

Go into the new theme (Manage > Manage Site Theme > Manage Pages) and recreate the custom pages you need there - they won't carry over automatically. For one of your test pages, try committing/publishing that staged change and then hitting the URL again - if it starts working, that pretty much confirms the theory above.
Before you cut over, I'd also do a full pass of every custom page URL on your live site and make sure each one has a matching page built in the new theme - much easier to catch gaps now than after launch.
If you rebuild a page, publish it, and it's still throwing that error, that's the point where I'd loop in Verint Support directly - on hosted instances there are cases where an app pool recycle is needed to pick up new routes, and that's not something you can trigger on your end.

If you're open to sharing your exact build number and one example URL, I'm happy to help keep digging on our side too, to determine whether this is just how theme scoping works or something worth flagging to Verint as a bug.

Good luck with the launch!

RE: Custom Page - Internal Server Error

Matt — Mon, 14 Sep 2026 12:00:08 GMT

Which version of Verint are you using?

You'll likely find something useful in Administration > Monitoring > Exceptions.

RE: Removing Broken Bookmark Items

Satish Kumar (3sides) — Mon, 31 Aug 2026 05:43:20 GMT

You can remove a bookmark using the Script API’s **Delete** method:

https://community.telligent.com/community/13/w/api-documentation/72620/core_5f00_v2_5f00_bookmark-script-api?utm_source=chatgpt.com#Delete

Please note that the code must be executed in the context of the user who originally created the bookmark.

Removing Broken Bookmark Items

Eion Ness — Wed, 26 Aug 2026 13:36:09 GMT

I have a bookmark on a user that has a contentId and a contentTypeId but all other aspects of the bookmark object are empty. This is resulting in bookmark.list breaking for the user and a forceful delete of the object returns an error since the item cannot be found. I can get the base item by using core_v2_content.get but obviously cannot delete the item from that point. Is there a way to bypass the safety check and just delete the item so that my user can see all their bookmarks again?

Error message when viewing calendar event

Marisa — Tue, 18 Aug 2026 19:18:31 GMT

Good day forum,

We're setting up a new calendar, and this will be our first time using it to this extent. After adding events, on the event page I'm seeing the following error:

I have checked permissions on all possible levels, both the Group and Calendar levels. I'm seeing this for both anonymous and registered users.

The group where the calendar lives is joinless, and the event also doesn't require registration (we're using Teams for registration - this is more for the visual).

I cannot for the life of me find where this error is coming from. I've also checked all the widgets on the page - they were both reverted to default and the only custom edits are the resources (we have multiple languages).

I'm using version 13.0.2.33658 (there is a bug blocking us from upgrading)

We did find this bug in the Release notes:

TE-19274 - Fixed issue with creating calendar events error due to no event registration being present

But it doesn't feel like THIS particular issue, but I could be wrong. I appreciate any insights :)

Thanks so much!

RE: Error message when viewing calendar event

Sara Collins — Sun, 23 Aug 2026 21:09:21 GMT

Hi Marisa

A couple of things worth checking that go beyond the Group-level and Calendar-level permission grids you've already reviewed:

Check the permission set on the Calendar item itself, separately from the Group's role matrix. Calendar event permission checks are evaluated against the specific Calendar object's own permission set, not just the Group's default application permissions (this was the subject of an older fix, TE-17127, which corrected CalendarEventContentType.HasPermission to check at the Calendar level rather than the Group level). If this Calendar was created and never had its own Permissions tab explicitly opened and saved, it's possible it doesn't have a fully generated permission set — even though the Group's roles look correct. Try going into Manage this Calendar > Permissions directly (not the Group's Roles/Permissions page), confirm the roles/Everyone are listed with View, and hit Save even if nothing looks different, just to force the permission set to (re)generate.
Rule out caching. Permission changes at the application/content level don't always propagate immediately. After adjusting permissions, try an app pool recycle or a cache clear if you have access, then retest in an incognito/anonymous session.
Since you're seeing this for anonymous and registered users (including presumably higher-privileged accounts), that pattern is more consistent with a broken/missing permission entry on this specific Calendar than a role-configuration gap — which is what points me at #1 above rather than another pass through the Group permission matrix.

TE-19274, for what it's worth, looks like it's scoped to the event creation/registration button flow rather than viewing permissions, so I'd agree that's probably not your culprit.

If none of that turns it up, this feels like a case worth opening with Verint Support directly with a repro — a 403-style permission error hitting anonymous, registered, and apparently admin-level users on a single calendar smells like a data/config edge case in how that Calendar's permission set got created, rather than something fixable purely from the UI.

Hope that helps — let us know what you find!

RE: Any idea when 13.0.5 is likely to be released?

Jon Allen — Fri, 14 Aug 2026 23:29:51 GMT

We are 2 weeks out. Just finishing up with final QA and release notes.

Any idea when 13.0.5 is likely to be released?

Liz Morgan — Tue, 28 Jul 2026 15:10:52 GMT

Hi,

Just wondering if there was any news on the 13.0.5 release date? We're waiting on a fix TE-19591

Jon Allen would you have an ETA?

Thanks,

Liz

What's considered a download?

Liz Morgan — Tue, 11 Aug 2026 15:37:25 GMT

In our v13 community, we've noticed that a particular video in a group media gallery has been doing very well - it's been downloaded 300 times. "Great!" I thought to myself as I headed to the video to see what was so interesting about it. However, when viewing the figures, as per 'How do I see download counts of files in a media gallery, I noticed my name in the stats. I definitely did not download the video, I merely viewed the page, I didn't even play the video! 😮

So, my questions:

Has anyone else noticed this?
Is it intended behaviour?
Is it a known bug (that I didn't know about)?

Looking forward to any replies 🙂

Thanks

Liz

RE: What's considered a download?

Liz Morgan — Wed, 12 Aug 2026 09:33:26 GMT

Hi Sara Collins

I'm glad it wasn't just me :)

Your best guess sounds entirely plausible, it's just not very clear that is what's happening.

I've raised a support case (1559363) and will update this thread when I hear more.

Thanks for your reply.

RE: Is there a way for a user to leave a Group without the widget?

Rachel Jackson — Tue, 11 Aug 2026 19:04:58 GMT

Thank you Sara for confirming my hypothesis. Seems like an opportunity missed in the "Subscriptions" control under Profile. I'll be adding it to the Ideas for future consideration.

Is there a way for a user to leave a Group without the widget?

Rachel Jackson — Thu, 06 Aug 2026 17:51:43 GMT

We have community members looking to leave a group, but the Group Owners didn't insert the widget that allows a user to toggle their membership.

Is there another way a user can leave a group without Administrative or Owner engagement, or is the widget the only option?
It looks like you can unsubscribe from applications and content in your settings, but not leave the group.

Subscription Management Bundle Implementation Strategy

kbaumer — Wed, 22 Jul 2026 16:03:18 GMT

We're implementing the Subscription Management Bundle and would love to hear how others approached rollout and configuration.

A few questions we're working through:

How did you handle existing members versus new members?
Did you start with a limited set of subscriptions/notifications and expand over time, or implement everything at once?
What notification cadence have you found most effective (real-time vs. digest)?
Were there any settings or combinations that generated more notifications than expected?
Looking back, is there anything you'd do differently?

Our goal is to improve visibility into discussions and community activity while avoiding notification fatigue, so we're trying to strike the right balance before enabling automations at scale.

Any lessons learned or recommendations would be greatly appreciated.

RE: Subscription Management Bundle Implementation Strategy

Sara Collins — Tue, 11 Aug 2026 19:03:44 GMT

HI kbaumer

This is such a great set of questions — happy to share what we've seen across the communities we've rolled this out for.

On existing vs. new members: we'd recommend scoping the automation rules to new registrants and new group joins only, and handling your existing member base as a separate, deliberate step rather than folding them in automatically. Silently changing notification settings for people who are already used to their own preferences tends to generate more "why am I suddenly getting these emails" tickets than it's worth — a short heads-up communication (or even a one-time opt-in prompt) tends to land much better than a backend change they didn't ask for.

On phased vs. all-at-once: start narrow. Pick one or two groups/applications to pilot the digest and default notification rules on first, watch the volume and feedback for a couple weeks, then expand from there. Rolling everything out simultaneously across all groups makes it much harder to trace back which rule is generating the noise if members start complaining about fatigue.

On cadence: weekly digest has been the sweet spot for most communities we've worked with — it keeps people engaged without feeling like a firehose. Daily digest can work for smaller, high-traffic groups where content moves fast enough that weekly feels stale. We'd reserve real-time/live alerts for the genuinely high-value stuff — direct mentions, replies to their own content — rather than general activity, since that's usually where real-time notifications start to feel excessive fast.

On settings that generate more than expected: keep an eye on the combination of group-triggered subscriptions stacking with individual content subscriptions — if a member is in multiple groups that each apply their own digest/app subscription rules, they can end up double- or triple-subscribed to overlapping content without anyone intending that. Also worth checking network activity + content interaction notifications together, since those two categories tend to compound quickly at scale.

Looking back, the biggest thing we'd tell anyone implementing this: communicate the change to members before it goes live, not after. Giving people a heads-up and a clear, easy way to adjust their cadence (or opt out) up front heads off a lot of the "notification fatigue" complaints before they start.

RE: Is there a way for a user to leave a Group without the widget?

Sara Collins — Tue, 11 Aug 2026 19:01:39 GMT

Hi Rachel Jackson

Good question — I actually dug into this recently for a similar situation. As far as I can tell, the widget really is the primary front-end mechanism Verint provides for a member to self-toggle their group membership — I couldn't find any documented alternative for a user to leave a group entirely on their own without it. The unsubscribe options in Settings only cover notifications/content subscriptions, not actual group membership, so that lines up with what you're seeing.

The good news is there's an easy fix on your end: since you likely have Admin access, you (or the Group Owner) can add the Group Membership widget to the group's page via Manage > Manage Group > Design, which will restore the self-service toggle for members going forward.

In the meantime, until that widget's added, the only way for a member to leave is for an Admin or Group Owner to remove them manually through Manage > Manage Group > Members.

I haven't found anything indicating this is configurable another way (e.g., via a settings page), so I'd treat the widget as required if you want members to be able to leave on their own. Happy to compare notes if you find anything different on your end!

RE: Copying and republishing forum content

Sara Collins — Tue, 11 Aug 2026 18:53:04 GMT

Hi Marie.Cassidy

This comes up more than people realize, so happy to share how we typically walk clients through it. A few tracks, roughly in order:

1. Start with a direct, assume-good-intent message to the user. Most community Terms of Use (Verint's included) already state that content posted in the community can't be redistributed elsewhere without permission — even though the poster technically owns their own words, republishing full threads on an external site like GitHub almost always violates that clause. A quick private message citing the specific guideline and asking them to take it down is usually the fastest resolution, and it gives the user a chance to comply before anything more formal.

2. If they don't respond or refuse, escalate through your code of conduct. Since this is a clear ToS violation (not a judgment call), it supports a moderation action — a formal warning, content restriction, or suspension depending on severity and whether it's a repeat pattern.

3. For GitHub specifically, you have two real reporting paths, and which one you use matters:

If this is about your organization's or customers' proprietary/copyrighted content, file a DMCA takedown notice at github.com/contact/dmca. You'll need to name the copyrighted material, give exact URLs/file references, and include a "fair use considered" and perjury statement — GitHub publishes the redacted notice, so it's a bit more formal, but it's also the fastest way to force removal since GitHub has a legal obligation to act.
If it's more about exposed customer names, PII, or content that isn't cleanly "copyright" (just a clear community guideline violation), GitHub also has a general content/abuse report flow that doesn't require the DMCA formality and can move faster for non-copyright cases.

4. Loop in legal/comms early if customer content is involved — not just yours. That shifts this from a moderation issue to a data handling one, and it's worth having that team aware before you escalate externally.

5. Document the pattern. Even if this resolves with one polite message, keep a record — repeat offenders or repeat incidents make the case for tightening policy or taking harder action later.

On prevention: if your current guidelines only imply "no redistribution" via general copyright language, it's worth adding an explicit line calling out cross-posting/mirroring content on external sites as a violation — and giving users an approved alternative (e.g., "share the link, not the content") so there's a legitimate way to reference forum discussions elsewhere.

Hope that helps — happy to compare notes if you end up going the DMCA route, curious how GitHub's turnaround time is these days!

Thank you,
Sara