Timeline Grouping without Group ID in event

[Thomas Pentenrieder]

I have a very similar setup to this with one person belonging to a single group (project in this case). I store the groupId in the person entity.

Now the event still also needs the groupId of the person to be shown correctly. Is there a way around that, so we don't need to store the groupId with the event? This seems redundant and whenever a person changes to a different group we need to update all the event entries in the database as well.

[Vijay Ravi]

Hi Thomas Pentenrieder,

Greetings from Syncfusion Support,
 

We have checked and validated your reported query for your requirement. Currently, Syncfusion Scheduler mandates groupId in event data for proper resource grouping. Without groupId in events, dynamic grouping or resource reassignment won’t render correctly. You must update event records when a person’s group changes in the database to maintain UI consistency.

Don't hesitate to get in touch if you require further help or more information.
 

Regards,

Vijay

[Thomas Pentenrieder]

I was afraid so. Could you track this as a feedback / feature request? From my POV there is no technical necessity for this, at least not for my 

[Vijay Ravi]

Hi Thomas Pentenrieder,
 

We have reviewed the possibilities regarding your requirement. In the Resource Grouping section, when assigning a specific person to a different group, the updated data for the respective events must be manually updated in the database for the changes to reflect in the UI. This is the current scheduler behavior, and unfortunately, there is no possibility to consider implementing it as an additional feature currently.

Don't hesitate to get in touch if you require further help or more information.
 

Regards,

Vijay

[Viller blender]

In this setup, storing the groupId directly on each event may feel redundant, but it is often the most practical approach for proper timeline grouping and efficient querying, especially when rendering events quickly without performing additional joins on the person entity each time. However, if your system supports relational mapping or dynamic lookups, you can avoid duplication by resolving the groupId through the linked person record at runtime, which keeps your database normalized and prevents the need to update all historical events when a person changes groups. Another approach is to create a computed or virtual field that derives the group from the associated person, allowing cleaner data management while preserving display accuracy. Much like structured FPSC MPT preparation, where organized data and efficient access to information are essential, choosing the right schema design depends on balancing performance, maintainability, and long-term scalability.

[Vijay Ravi]

Hi Viller blender,

As mentioned in the previous update, when the resource is scheduled and the FieldID is set, the GroupId must be provided while initializing the event to create an appointment. Additionally, when events are created dynamically, the GroupId is generated dynamically and assigned to the corresponding event. This is the expected behavior.

https://ej2.syncfusion.com/react/documentation/schedule/resources#resource-fields
 

Regards,

Vijay