Workflow Sample: Episode 545: Easy Management of Mailing List by Cooperating with Google Group (3)

Maintenance on Google Group registrants

In the last article and the one before the last, I introduced you Business Process Definitions which automatized addition or deletion of members of "Google Group" to be carried out.

If Google Group is being used as "In-house information sharing tool" in your company, these functions such as automatic addition and automatic deletion could be very useful as "mechanism to guarantee timely update".

Height of reliability requirement

However, even if you introduced such a mechanism, "maintaining correct members" is not easy.

In some cases, for example, you could have added a member to a "wrong group" (system administration screen) in corresponding to a rush-request. Or, there may be cases where a user him/herself commits "unsubscribe processing" (User setting screen). Those cases are state of "Information will reach people who should not reach" or "Information does not reach the person to reach".

"What? Was there such a notification?"

An employee worked without receiving information via mailing list for months feeling something was strange. That kind of Tragedy (which is a very terrible thing) will always occur someday.

[ML Member Confirmation]

Risk mitigation measures

This Business Process is to automatically acquire the member list of a Google Group and automatically sending it to the members of the Google Group.

For example, each member of "Sales team 3 ML" will receive "email with the mail address of all the members of the team 3 in its body" at 7 a.m. on the first day of every month. For another example, each member of the "ISMS achievement project" will receive an "email with the email addresses of all who is concerning with the project in its body" at 7 a.m. on the first day of every month.

Certainly, even if this mechanism is introduced, a person who has not received cannot notice that "he/she has not received" by him or herself. However, someone who has received will be able to notice that "not being received by the person who should receive". And secondarily, it could be also an opportunity to re-recognize that "such people are also receiving the same information".

In other words, this scheme is recommended to be operated on the Google Group which should be always kept an eye on the scope of information disclosure, such as "Mailing list for the Board of Directors" or "Mailing list of which external collaborators are participating". (Naturally, if external collaborators are included in the member, the email addresses of all the subscribers is disclosed to these external collaborators as well.)

* Needless to say, Google Group which is under a rule that not to share each email address within Group is out of assumption. (E.g. "All Clients")

Utilizing unmanned Step

Here, three unmanned Steps ("added Service Tasks") are utilized: [ML number acquisition] [ML selection] [ML member acquisition].

In [ML number acquisition], the number of lines of "Monitored Mailing List" (multi-line character string) is automatically counted and the number of loops is set. In [ML selection] and [ML member acquisition], subscriber of Google Group which is written on line N, is requested via API. (OAuth2 request is automatically sent to "Admin SDK Directory API v 1" as server side processing of the workflow system.)

And then it flows immediately after to the email notification event to automatically send the "Google Subscriber List".

In addition, it is also worth considering a Business Process in which the email notification destination is fixed to the information system department, and the staffs of the department perform the member maintenance responsibly.

[ML Member Confirmation:"1. Monitoring target check" screen]