Hi,

After a few discussions in our development team we've decided to ask the community on the following matter.

We are at the start of a new project where we will create a communication platform for customers to communicate through a portal with the employees of a company. The MVP would be that a message could be send by the customer with a certain subject. Based on the subject it would be send to the taskbox of a specific department where the subject belongs to.

However in the future we would like for a department manager to be able to send a task to a specific team inside the department. And in side a team it would be possible to send it to a user(employee) within that team.

So with the future in mind what would be a good way to develop this and we thought of the following:

1. Departments and Teams are both OutSystems Group.
This would be an obvious decision when using BPT in OS. However Departments and Teams would be considered on the same level. So users belong to a department and users can also belong to a team. However in reality a department has teams and teams have employees. We where wondering if this would cause confusion in the future. I think it is not possible to have an OS Group that has other OS Groups inside them.

2.We ignore OS groups and use our own designed entities
So instead of using groups we build entities Department, Team and TeamMember. In this case a Team entity has a Department.id which it belongs to a department and a TeamMember is a combination of the OS UserID and a Team.id. Then in BPT we create our own logic to assign things to the right team/department. We have thought of this to have control and have the reality be represented in out design. However we don't know if this is going to bite us in building this.

3.Hybrid solution Team is an OS Group and Department is an Entity.
So this would be a hybrid between 1 and 2. Where we put all the teams inside OutSystems Groups and create a separate entity for Departments. Then we still need a entity which connects teams to departments, but the reality is still in the design.

Our questions:

1. Which option is the best to work with and why?

2.Are there any alternatives we might want to consider also?

3. What are the pitfalls we need to watch out for? 

We are probably not the first developers to try and realize a hierarchy that is more complex than just groups and users so please advice us.


Thank you.






 

Hi Robert, 

You may consider using a "Behaviour" approach: https://medium.com/@joaoheleno/enhancing-outsystems-bpt-processes-with-behaviours-897f8c36c237

In any case, thinking on the future and on your subject, there is something it is not clear for me.

When the "Department" receives the communication, WHO in the department should take care of it? Anyone at first? A specific person, like the Department Header? A group of persons inside the Department?

And when someone in the "department" sends the task to a "team", WHO in the team will have to deal with it (or assign to a specific user)? Anyone? A Team Leader? 

The problem with using groups per se is that anyone in that group will be able to deal with the task (unless you implement a "behaviour"), independently of the employee's Team. The same thing when the task is sent to a Team group. 

So, I don't think using the "group" is bad per se, and I don't see a problem using them first if anyone will be able to handle the task (we think the right person will assume the task). 

You are right that there are no groups inside groups. If you create a Department group and Teams groups, a user will be in more than one group at a time. This is not a problem. In the first stage you send the message to the "Department" group, and anyone in that group (regard of the team), will be able to see the message.

In a second approach, you send to a Department responsible to assign tasks to teams, and he chooses which Group (team group) to receive the message next. And in a third step, when chosen the team group, you assign the task to a team leader, that has the ability to send the task to a specific user.

Everything on a "sequence of events" in the process. 

BUT... You will have to deal with many groups, and probably create/manipulate them dynamically (not through the Users application). Not that difficult, of course.

The behaviours would enable you to specify when passing from receiving the message to a department, who would deal with the message (send to a team) then another behaviour would define who in the Team would be able to assign to a specific user.

I think :)

Thank you for the response. We decided to start building from these tables to be flexible, because we ended up with the same questions and we don't have the answers and the company does not have them either.

It seems to me that if you have a Team/Team_User and a Department, you probably don't want to use the Groups... You are adding another layer that does not seems to bring any benefit to your use case. 

Instead, I would use the Behaviour concept (with its own entity) to specify who can execute actions on each Human Activity, based on what step of the flow the process is...

Less confusing, not using something (groups) that do not really fit in the context...

Thank you very much for the quick responses!

Yes you are right that groups now seems less usefull. However if a subject of a message will point to a groupId it would be more flexible. Because a group can be a Team or a Department. Another solution will be to have both departmentId and TeamId inside the Subject Entity. 

We are now questioning if not leveraging on OS Groups is going to make it that much harder or if it is not that big of a deal.


Hi Robert,

I think you can use groups, in the end, that would make life easier, but I am still thinking that an approach using "Behaviours" would be even easier.

I'll try to implement a small example, based on your use case, so you can see. As soon as I can get it done, I'll put it here (maybe tomorrow). 

Cheers.

I also started to do some asking around, but most people don't like the complexity of queries that you might need in the future using groups.

Solution

I would say that using groups for departments and teams is not a bad choice.
You can create a hierarchy between them, setting the has_custom_management attribute of the group entity (they will not appear in the Users application), and creating entities to create the hierarchy and a back-office to deal with them. 

This way the complexity is not really that big. You can have your department groups (and the users defined in them), and your Teams groups, and the users defined in them (no user from other departments should be allowed in a team of a department, for example).

This makes your process "easier", as you can, on each step, defined who can deal with the task based on the group, that could be a department group or a teams group, and later on make it finer by deciding who in the group has to deal with it, through behaviours, for example.

Something like this:

So, you have a "Unit" extension, that says if a group is a Department or a Team, and at the same time defines the hierarchy. In your process when the message is created, you sort which department to send the message based on subject, and triggers a human activity to the department group.

In a second step, you define behaviour that only the department responsible can deal with the task, for example, and its action must decide to which team to send, as you have the hierarchy it is easy to give them the option and on selecting, you trigger a new human activity to the correct group (easy to fetch).

In a third step, you can define behaviour that will make only the team leader be able to deal with the task, and his activity is to choose to who it must be sent.

At least, if I understood what you need, would be easy to go from big picture to more detailed levels easily.

Solution