Tech Forum

I am a stake membership clerk. I recently accessed the Membership Record Validation Report on the stake computer. It seemed that some of the wards had not been making needed corrections.

Feedback from some of the ward membership clerks indicates significant differences between the data on the ward computer compared to the stake computer.

How is information from ward MLS updated to the stake computer?
From CHQ via send/receive? At what intervals?
From each ward directly to the stake?
Maybe both?

Thanks in advance for your assistance.

Ron

znauga wrote:Feedback from some of the ward membership clerks indicates significant differences between the data on the ward computer compared to the stake computer.

How is information from ward MLS updated to the stake computer?
From CHQ via send/receive? At what intervals?
From each ward directly to the stake?
Maybe both?

Information from ward MLS to stake MLS definitely comes only via Send/Receive, and only via CHQ -- there is no mechanism for wards communicating with the stake except through CHQ. Membership information goes to the central membership database, and then back to the stake; other information must be going to other servers where MLS information is then stored to be transmitted to the stake. Some information (e.g., temple recommend activation) goes from the stake to the wards.

As for the intervals, I'm not exactly sure. Some information such as membership record updates clearly goes from ward to CHQ, is processed within a matter of hours, and then is available for download by the stake. Other information was originally documented as being sent automatically only monthly -- that's why there is an option on the ward MLS File menu for "Send Membership Data to Stake"; using that option forces all membership data to be sent to CHQ, and again within a few business hours it is available to the stake. But I'm not sure just what data fits into that category.

I also have noticed that there are some differences at the stake level regarding households, particularly those that include nonmembers. Stake MLS has some limited ability to change who is in households, but I believe such changes only affect the MLS record of households. Since it doesn't flow back to the ward, obviously that could be a source of differences.

Alan_Brown wrote:Information from ward MLS to stake MLS definitely comes only via Send/Receive, and only via CHQ -- there is no mechanism for wards communicating with the stake except through CHQ. Membership information goes to the central membership database, and then back to the stake; other information must be going to other servers where MLS information is then stored to be transmitted to the stake. Some information (e.g., temple recommend activation) goes from the stake to the wards.

As for the intervals, I'm not exactly sure. Some information such as membership record updates clearly goes from ward to CHQ, is processed within a matter of hours, and then is available for download by the stake. Other information was originally documented as being sent automatically only monthly -- that's why there is an option on the ward MLS File menu for "Send Membership Data to Stake"; using that option forces all membership data to be sent to CHQ, and again within a few business hours it is available to the stake. But I'm not sure just what data fits into that category.

I also have noticed that there are some differences at the stake level regarding households, particularly those that include nonmembers. Stake MLS has some limited ability to change who is in households, but I believe such changes only affect the MLS record of households. Since it doesn't flow back to the ward, obviously that could be a source of differences.

The "problem" with the Validation Report may be that on the ward level there is an option to ignore identified warnings/errors which cannot be resolved by modifying the membership record. Since the record is not modified there is no change at the Stake level?

Example: Missing name of a father on a child record. Mother declines to provide a name. The ward membership clerk selects "ignore." The record is dropped from the Validation Record in the Ward MLS. However, no change is submitted to CHQ, therefore none forwarded to the stake.

Is this possible?

Ron

znauga wrote:The "problem" with the Validation Report may be that on the ward level there is an option to ignore identified warnings/errors which cannot be resolved by modifying the membership record. Since the record is not modified there is no change at the Stake level?

Example: Missing name of a father on a child record. Mother declines to provide a name. The ward membership clerk selects "ignore." The record is dropped from the Validation Record in the Ward MLS. However, no change is submitted to CHQ, therefore none forwarded to the stake.

Is this possible?

Yes, this is possible. The option to ignore identified warnings or errors on the Membership Record Validation Report seems to be specific to the unit. By this I mean that a ward can ignore a certain set of issues, and the stake can choose to ignore an entirely different set of issues for that ward. There is no connection between these choices.

It seems like it would be helpful to have a way to see the set of ignored issues, and to reset the "ignore flag" for particular issues (or perhaps for the whole set of ignored issues). That would give wards and stakes a tool to track down differences that might be attributable to different choices as to which issues should be ignored.

Alan_Brown wrote:Yes, this is possible. The option to ignore identified warnings or errors on the Membership Record Validation Report seems to be specific to the unit. By this I mean that a ward can ignore a certain set of issues, and the stake can choose to ignore an entirely different set of issues for that ward. There is no connection between these choices.

It seems like it would be helpful to have a way to see the set of ignored issues, and to reset the "ignore flag" for particular issues (or perhaps for the whole set of ignored issues). That would give wards and stakes a tool to track down differences that might be attributable to different choices as to which issues should be ignored.

Thank you for a quick response. I may need to apologize to some clerks for having so many records in need of corrections which they may have already resolved to the best of their ability.

An associated problem is that as records are transferred from ward to ward members are being asked the same questions repeatedly. Uncomfortable for an unwed mother to be asked for the name of the father of her child which she declines to put on the membership record. Also extra work for diligent clerks.

Ron