# Use user-defined segment in a plugin

**URL:** <https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556>\
**Category:** Help me!\
**Tags:** typescript, agent\
**Created:** [October 22, 2024, 9:11am UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556 "2024-10-22T09:11:04Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![kll](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/kll/32/7091_2.png) [@kll](https://community.forestadmin.com/u/kll)\
**Post date:** [October 22, 2024, 9:11am UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/1 "2024-10-22T09:11:04Z")

</div>

## Feature(s) impacted

Using the FA API with segments inside a plugin.

## Observed behavior

I have segments defined both in the backend and in the front-end.  
However, only segments created on the backend via `addSegment` calls on `CollectionCustomizer` seem to work.

Sample code:

```typescript
async function myPlugin(
  dataSourceCustomizer: DataSourceCustomizer,
  ...
) {
  const dataSource = await dataSourceCustomizer.getDataSource(someLogger)
  const results = await dataSource.getCollection(someCollectionName).list(
    someCaller,
    new PaginatedFilter({
      segment: 'My front-end defined segment',
    }),
    myProjection,
  )
  // ...
}

```

The above code will simply query the collection, without any use of the segment.

## Expected behavior

I would like to be able to use both kinds of segments in calls to `Collection.list`.

## Failure Logs

N/A, if the segment is not found then the API simply ignores it.

## Context

- Agent technology: nodejs
- Agent (forest package) name & version: 1.50.1 with sequelize 6.37.4
- Database type: MSSQL

---

<div class="post-metadata">

**Author:** ![anon7284711](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@anon7284711](https://community.forestadmin.com/u/anon7284711)\
**Post date:** [October 22, 2024, 9:23am UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/2 "2024-10-22T09:23:45Z")

</div>

Hello @kll,

Sadly this is not possible as segment defined in the frontend are only present and defined in the layout of the team in which they have been created. They are not propagated to the agent.

What would be the use case of your plugin ? We may be able to find another solution 🙂

Happy to help,

---

<div class="post-metadata">

**Author:** ![kll](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/kll/32/7091_2.png) [@kll](https://community.forestadmin.com/u/kll)\
**Post date:** [October 22, 2024, 9:29am UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/3 "2024-10-22T09:29:45Z")

</div>

Hi @anon7284711,

That’s too bad. I wanted to use user-defined segments coupled with some light configuration to allow for notifications to be sent when entities enter some segments.

For example: when a customer enters the “newly upgraded” segment, send a notification to our Teams channel.

This would have allowed me to use user-defined segments as filters, offloading the task to Forest users.

Using Forest for notifications would be _so much simpler_ than using my backend, for compliance and reliability reasons. I hoped to use segments as a way to kickstart the process.

---

<div class="post-metadata">

**Author:** ![anon7284711](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@anon7284711](https://community.forestadmin.com/u/anon7284711)\
**Post date:** [October 22, 2024, 10:03am UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/4 "2024-10-22T10:03:42Z")

</div>

I’m not sure I’ve fully grasped your needs, what is the “newly upgraded” segment (frontend defined or via code inside the agent) ?

Are you exposing the UI to customers and would like to monitor the usage of segments (both types) ?

I am also noting that you are interested in a way to notify your team via the agents, I’ll forward that to our product team 😉

In any case, the frontend is sending the `segmentName` query param to the agent when the user is viewing the records via a segment (be it frontend defined or via code), the only limitation is that when the segment is defined on the frontend, the call will contain both filters defining the segment and any additional filter the user may apply, making it a bit blurry if you want to fetch the exact definition of the filters for a segment defined in the frontend.

---

<div class="post-metadata">

**Author:** ![kll](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/kll/32/7091_2.png) [@kll](https://community.forestadmin.com/u/kll)\
**Post date:** [October 22, 2024, 12:08pm UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/5 "2024-10-22T12:08:48Z")

</div>

> [@anon7284711](#):
>
> I’m not sure I’ve fully grasped your needs, what is the “newly upgraded” segment (frontend defined or via code inside the agent) ?

Ah, it was just a random example. I could want to send notifications on recent new records, records that had a state flag changing (`PendingReview` becoming true for example), or other criteria. Ideally, these criteria would be defined on the front-end.

> [@anon7284711](#):
>
> Are you exposing the UI to customers and would like to monitor the usage of segments (both types) ?

No this would be an internal plugin, unplanned for release, and without any UI.

> [@anon7284711](#):
>
> In any case, the frontend is sending the `segmentName` query param to the agent when the user is viewing the records via a segment (be it frontend defined or via code), the only limitation is that when the segment is defined on the frontend, the call will contain both filters defining the segment and any additional filter the user may apply, making it a bit blurry if you want to fetch the exact definition of the filters for a segment defined in the frontend.

Yep so there isn’t a right way to get these segment definitions… I can think of a couple _wrong_ ways but I’d rather not. I might just have to give up on this topic for now.

---

<div class="post-metadata">

**Author:** ![anon7284711](https://avatars.discourse-cdn.com/v4/letter/a/ac8455/32.png) [@anon7284711](https://community.forestadmin.com/u/anon7284711)\
**Post date:** [October 22, 2024, 12:28pm UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/6 "2024-10-22T12:28:57Z")

</div>

> I could want to send notifications on recent new records, records that had a state flag changing (`PendingReview` becoming true for example), or other criteria.

It was funny for us to see your topic about sending notifications because the tech team was working on something similar during our last on-site event, you can see the [PR on our agent here](https://github.com/ForestAdmin/agent-nodejs/pull/1189/files). Not via the UI sadly as this is a quick project strapped together by the tech team in 1 or 2 days.

> I can think of a couple _wrong_ ways but I’d rather not. I might just have to give up on this topic for now.

Sorry that we couldn’t find a solution.

---

<div class="post-metadata">

**Author:** ![kll](https://dub1.discourse-cdn.com/flex013/user_avatar/community.forestadmin.com/kll/32/7091_2.png) [@kll](https://community.forestadmin.com/u/kll)\
**Post date:** [October 22, 2024, 12:59pm UTC](https://community.forestadmin.com/t/use-user-defined-segment-in-a-plugin/7556/7 "2024-10-22T12:59:23Z")

</div>

> [@anon7284711](#):
>
> It was funny for us to see your topic about sending notifications because the tech team was working on something similar during our last on-site event, you can see the [PR on our agent here](https://github.com/ForestAdmin/agent-nodejs/pull/1189/files). Not via the UI sadly as this is a quick project strapped together by the tech team in 1 or 2 days.

I mean, with your validation features and other workflows, it almost seems surprising that FA doesn’t already allow this kind of internal notification 😃  
They would pair superbly with [inboxes](https://docs.forestadmin.com/cloud/native-modules/inbox)… right now inboxes are just segments, but in a new place. Slap in some notifications and it’s an essential.

> [@anon7284711](#):
>
> Sorry that we couldn’t find a solution.

It was a long shot anyway.