Connection & autoactions

I want to create automatic connections between a user with a "member" profile and another with an "author" profile.
Automatic login should occur when a specific user group is assigned to the "member" user.
Also the connection should be deleted when the "member" profile is removed from the user group.
Is this possible with autoactions?

I want to create automatic connections between a user with a "member" profile and another with an "author" profile. Also the connection should be deleted when the "member" profile is removed from the user group.

Yes, there's a Connection auto action type specifically for establishing (and deleting) connections. Profile type doesn't really matter to that auto action type. It specifically works off their user id.

Automatic login should occur when a specific user group is assigned to the "member" user.

Not sure what you mean by this. When should they be automatically logged in?

I did not find these auto actions in the system so good news that these auto actions exist.

The practical case:
"Author" profile has a custom field in which the usergroupid its user group is saved.
When the profile of a "member" user is edited or updated automatically by including it in a usergroup, if the id of the usergroup (in which it has just been included) is the same as the value recorded in the field personalized of the "author" profile then a connection must be created between the "member" user and the "author" user.
The reverse when the user "member" is removed from the usergroup.

That's a bit more complicated. If I understand you correctly you have something like the below.

User A (author) has a field where they select a usergroup
User B (member) is edited and assigned that usergroup

In the above case when User B is assigned that usergroup you need to establish a connection to User A. The only real way to do this is for when User B is updated scan through every user in your database finding users with field values matching one of the usergroups assigned to the user. That's doable with Custom User parsing behavior, but again that's complicated as you've to code that entire check yourself.

Can User B be assigned to multiple authors? Does this really need to be done using usergroups (e.g. are you using the usergroups for actual ACL control)?

There is a specific usergroup for the authors which includes all the authors (ex: authors_group with usergroupid = 1) and there is another usergroup for the members of each author (ex: author_a_members_group with usergroupid = 2)
Specifically how this can be done with a autoaction ? :
"member user" is updated
- it is included in a "usergroup"
no ? -> do nothing
Yes ? -> look in the members belonging to the usergroup of the authors <authors_group> (usergroupid = 1) who has in a custom field the same value as the usergroupid <author_a_members> (usergroupid = 2)
find ? -> create the connection between author and member
Is my description more readable this way?

Why are you using usergroups for this? Are you actually using those groups to control access on your site? If you aren't you should not be using ACL as it will bloat it and slow your entire site. ACL is accessed basically everywhere and on all pages. It should be kept at a minimum and used as necessary. It should not be used as a means to link users together as that can be done using fields.

One way to do this more clearly is to create a usergroup for all authors. Place them in that usergroup then use a Query Select field provided by CB Query Field to query for all users with that usergroup. This will give a dropdown of every user assigned to that group. Next set it to not display on profile edit or registration. Now it will only be accessible in backend (you can alternatively use CB Privacy to limit profile edit access to moderators only). You'd then be able to easily use that field to establish your connection.

I can provide example configuration of the above if it sounds more appealing than your ACL approach. If however you absolutely need those usergroups then your usage becomes significantly more complicated as you have no information stored on the user themselves to identify who they are assigned to since that's not how usergroups work.