Can I have more that 1 Appointments type Group? v8.8

aware_support wrote

. .

@[deleted]

I have an Appointments Group containing 5 Appointment objects with a large amount of records. 40 fields in common. Works fine for 3+ years.
I want to create a new unrelated BO Group (So I can use the calendar).
When I make a new Appointment Object (default name is Appointment) it puts it in the existing Appointments Group and of course it adds the Required fields for Appointments.

This table has no fields in common with the previous 5 tables.
Do i add these same 40 fields even tho they will always be empty. If not, then my queries that use Appointments will not be able to access the fields because the new 6th BO doesn't have these 'common' fields.
Of course, then I have to add these new 10 fields to the other, logically-unrelated fields.

Am I missing something?
If I make a new BO Group, I can add the new table to it. But its still forced to be in the original Appointments group.
If I now remove it from that group, it removes the Scheduler fields and is no longer an Appointment object.

Any ideas?

Aware IM supports only one group for appointments that can be used in a calendar.

If you don't need the common 40 fields in calendars, then I suggest you create separate objects and separate groups for them. Objects that need to be displayed in a calendar can then have references to these other objects or groups and matching references on the other side. You can then have non-calendar queries that use the 40 common fields. And if these queries need calendar specific attributes you can always define shortcuts.

That's the only solution I can think of.

Create another group. Call it AppointmentsExtended. Find all the non calendar references to Appointmtents and redirect them to AppointmentsExtended.

Add your new BO to Appointments, now Appointments will only have the list of attributes available to Appointments.

AppointmentsExtended will have access to all of the extra attributes. Appointments will all show up in the Scheduler.

If those 40 attributes are not actually common to all the BOs in AppointmentsExtended then you can further break those into other BOGs.

The BOG defines the attributes available when referring to a BOG, not the full range of attributes available to the BO

eg.

Attributes of the BOG are driven by the maximum number of common attributes.

If you added BO1, BO2, BO3 to Appointments then it would add the attributes required for Appointments and the other BOGs would eb unaffected.