Ward Boundary Maps Detail

I'm curious if there's a way to further divide the ward map into zones for emergency preparedness purposes?

Bobbeo24 wrote:I'm curious if there's a way to further divide the ward map into zones for emergency preparedness purposes?

Yes, but not in the online map at maps.lds.org, if that is what you mean. Several others have suggested the same enhancement you have asked about. For example, seethis thread , this thread, or this one. The same basic functionality might be leveraged for other purposes, as well, such as unit boundary analysis, etc.

The MLS system in the clerk's office provides for the manual entry by clerks of arbitrary codes per household, in a field called the Ward Geo Code. But the actual geographic analysis (drawing the lines, determining who lives within them, etc.) must be done somehow outside of MLS, which remains geographically dumb.

One can export the households from maps.lds.org, including their lat/lon coordinates, as a CSV file and import that file somehow into external geographic software for display and/or analysis. But you are on your own for doing that.

At the simplest level of external software, there are map visualization tools such as Google Earth. See this thread, for example. At the far end of the spectrum, one might import ward data into a Geographic Information System, which is capable of doing what you ask and much more. But there is a significant learning curve involved with doing that. I am fortunate to have GIS software, within which I subdivide our ward into lots of different areas for different purposes -- fast offering districts, service project districts, what-if unit boundary analysis, etc. So defining emergency prep zones would probably be no big deal for me, but it took significant effort to build that general resource in the first place.

Fairly easy to do in Microsoft Streets & Trips.

aclawson wrote:Fairly easy to do in Microsoft Streets & Trips.

Could you expand on that? I have not used the S&T application, just read most of the Microsoft marketing stuff and browsed the user forums. If this relatively low-priced application really solves much of the problem at hand, I might try it, but I was not very impressed by my basic research.

• I can understand how S&T readily allows users to define what it calls "territories," so long as those territories are comprised of preloaded area-units including countries, states, zip codes and census tracts. But I can't see how those basic units can be split by the user if need be. Is that possible?
• I also understand that it is possible for a user to draw a single custom area, but that does not seem to be the same thing as a "territory," so does all the territory-oriented analysis functionality apply?
• Are there tools to draw multiple custom areas that fit perfectly against each other with common boundaries (with no overlaps or gaps)?
• Once these custom areas are defined within the application, can the user export the boundaries in some standard format so other users without the proprietary Microsoft software can import, display or print these boundaries?
• Can the user import any boundaries, such as the KML files exported by the church map sites?
• Can the user import address points already geocoded with lat/lon coordinates from some external source such as maps.lds.org, or does the application always rely on geocoding those addresses itself?
• From what I gather, the user can export a list of addresses to a spreadsheet grouped by territory. Does this also work with multiple, custom-defined areas?
• Does the exported file of addresses include the lat/lon of each geocoded point?
• Is there an ability to print maps, especially on a large printer format, that show both boundaries and family names as pushpin points?
• Can multiple family records (addresses) occupy the same pushpin location, and if so how are they displayed?

You are describing functions far beyond what S&T can do (Quantum can do those things but there is a significantly steeper learning curve).

1. A "territory" in S&T is just a map markup, as if you scribbled on a map with a pen. You can divide them as much as you want, just keep marking.

2. A "territory" is nothing more than a mark on the map.

3. Not really.

4. You can print the map to a .pdf form with the annotations showing and send them to anybody you wish.

5. You cannot import boundaries.

6/7. I'll get back to importing.

8. S&T does not claim exporting as a strong point.

9. Yes.

10. They can overlap somewhat making readability somewhat difficult to see.

Importing is something at S&T does fairly well. Set up an .xls or .xlsx spreadsheet, or a comma/tab delimited file would work (but not as useful). Within the spreadsheet place each "territory" on its own tab. You can then import each tab as a separate set into S&T and turn each set on/off as you see fit.

S&T has a free 30 day trial you can download - give it a try.

aclawson wrote:You are describing functions far beyond what S&T can do (Quantum can do those things but there is a significantly steeper learning curve).

1. A "territory" in S&T is just a map markup, as if you scribbled on a map with a pen. You can divide them as much as you want, just keep marking.

2. A "territory" is nothing more than a mark on the map.

3. Not really.

4. You can print the map to a .pdf form with the annotations showing and send them to anybody you wish.

5. You cannot import boundaries.

6/7. I'll get back to importing.

8. S&T does not claim exporting as a strong point.

9. Yes.

10. They can overlap somewhat making readability somewhat difficult to see.

Importing is something at S&T does fairly well. Set up an .xls or .xlsx spreadsheet, or a comma/tab delimited file would work (but not as useful). Within the spreadsheet place each "territory" on its own tab. You can then import each tab as a separate set into S&T and turn each set on/off as you see fit.

S&T has a free 30 day trial you can download - give it a try.

Sounds like there is a basic ability to draw freeform lines on a map and view/print the lines, and other users would have to view those lines in PDF/printed form or buy their own copy of S&T. That might be worth the purchase price, if that is all someone wants to do. For me it lacks appeal because I already have several other tools to do that, and I can more readily share the boundary files with others. However, it might meet someone else's more limited needs.

The relationship between lines and points within S&T still seems pretty weak. I don't want to determine myself -- visually or by some external process -- which members live inside which areas, then load them manually into S&T as you suggest. I would want to import all the member points and have the software tell me the areas in which they lie.

At this relatively low price point, for such a limited display application, my personal preference would still be DeLorme's Street Atlas USA Pro. Its users can also draw freeform lines and boundaries, and it can import boundaries. The print and display functions handles multiple families sharing the same point -- a case that tends to occur a lot in ward member files -- quite cleanly. But the export functionality is crippled. And like S&T, there is no point-in-polygon analysis.

The relatively dumb polygon drawing tools offered by either S&T or the DeLorme product -- without coordinated boundaries shared by multiple areas -- can be had for free in Google Earth or even Google Maps, which have good export functions to KML

I am still looking for a lightweight, easy-to-use, free or cheap app to recommend that would allow quick authoring/editing of multiple area (polygon) boundaries that fit together perfectly, as well as export functionality. Basic point-in-polygon grouping of points would be great, too, which begins to cross over into the world of GIS applications.

As you mentioned, free Quantum GIS can do that stuff but has a bigger learning curve.

Google Maps Engine Pro is easy to use. Costs is $5 per month. Here is our map below. Allows up to 10 layers with 200 entries per layer. Draw borders, add data tables, photos, custom icons etc. There is also a lite version for free with 3 layers and 200 enteries each. Both work slow on handheld devices but work well on tablets.... Phones not so good yet.. Imports csv from LDS Map. Does not Export any useful format...KML only which is only a GPS coordinate.

Evansmarketing@gmail.com wrote:Here is our map below.

You should probably remove that link from this public forum. It shows the locations and contact information from members of the ward, which likely came from MLS, and is considered confidential information. Whenever you use a third-party app you risk exposing church-controlled data to an uncontrolled place, which is bad form, on the one hand, and probably in violation of privacy laws and/or church policies about how you can use church data.

So, in addition to removing that link from this forum I think you need to take it off the web entirely. Such data should only be in the church's official Tools App, which is controlled by the church's own privacy and security protocols.

...unless I'm mistaken and those aren't the real names and addresses of real people, but it doesn't seem that way.

Looks like the policy has been updated. 4.9.3 seems to put an end to any mapping project.

4.9 MLS Data and Membership Information

4.9.1 Information about members, donations, and financial transactions is confidential and must be protected from unauthorized disclosure.

4.9.2 MLS data, database tables, or schemas must not be used or shared to create or assist in the creation of third party software.

4.9.3 The use of MLS data and membership information in third party software is prohibited, whether obtained from within or outside of a meetinghouse.

4.9.4 The use of cloud-based services for storing and/or backing up MLS or any membership related data is prohibited.

russellhltn wrote: 4.9.3 The use of MLS data and membership information in third party software is prohibited, whether obtained from within or outside of a meetinghouse.

That is going to be one tough policy to enforce. I've seen so many spreadsheets used by
wards for membership issues that it's hard to believe units are going to stop using them
altogether. Wonder if a privacy breach (or court case) prompted the policy change.

atticusewig wrote:

russellhltn wrote: 4.9.3 The use of MLS data and membership information in third party software is prohibited, whether obtained from within or outside of a meetinghouse.

That is going to be one tough policy to enforce. I've seen so many spreadsheets used by
wards for membership issues that it's hard to believe units are going to stop using them
altogether. Wonder if a privacy breach (or court case) prompted the policy change.

The general scope of that policy has not changed. It still applies only to meetinghouse computers "unless otherwise stated," so there is still nothing that regulates software on leaders' personal computers. And on meetinghouse computers, the term "third-party software" continues to be expressly defined in that context -- "any computer software program that was not created by the Church or is not approved for use on Church computers." A separate RKATS provision defining what is allowed on Church computers is quite open-ended, and obviously allows spreadseets. So using membership data in local spreadsheets, either on Church computers or personal computers, is not prohibited per se.

However, it is not the "third-party software" provision that really governs the Google Maps example described in recent thread comments here. That example is clearly "storing ... membership-related information" in "cloud-based services," which is prohibited by Section 4.9.4. That section has not changed, either, since it was promulgated in January 2014.

That provision about the cloud, I think, will substantially curb many practices adopted by local units, such as spreadsheets on Google Drive (aka Google Docs), as this provision becomes better known.

As for non-cloud mapping applications -- such as Google Earth opening local KML files, or any PC-based GIS software, etc. -- I see nothing in the policy preventing their use.

RossEvans wrote:The general scope of that policy has not changed. It still applies only to meetinghouse computers "unless otherwise stated," so there is still nothing that regulates software on leaders' personal computers.

This does not regulate what software can be on personal computers, but does regulate what can be used to handle church data.

To strongly limit what can be done with data on the church computer while giving free reign on personal computers makes no sense. I disagree with your interpretation.

russellhltn wrote:

RossEvans wrote:The general scope of that policy has not changed. It still applies only to meetinghouse computers "unless otherwise stated," so there is still nothing that regulates software on leaders' personal computers.

This does not regulate what software can be on personal computers, but does regulate what can be used to handle church data.

To strongly limit what can be done with data on the church computer while giving free reign on personal computers makes no sense. I disagree with your interpretation.

It's not my interpretation. It is the express language of the document.

Section 2 of the document defines its scope to cover meetinghouses "unless otherwise stated." It does not say, "unless otherwise speculated or inferred in forum comments" or "unless it 'makes no sense' to a Community Administrator on the LDS Tech Forum."

When the authors chose to expand the scope to include "cloud-based services," they did so explicitly. (Wherever the "cloud" is, it surely does not reside in the meetinghouse computer, so this expanded scope is otherwise stated within Section 4.9.4.) But there is not a scrap of language within Section 4.9.3 (the "third-part software" section) any other section of the document that makes it applicable to leaders' personal computers. It would only have taken a few words to expand the scope that way, but there is no such language.

So I will follow the actual language of the official document, not whatever policy we think the Church should have written so that it "makes sense" in forum folklore.

BTW, even on Church computers I don't agree that the Meetinghouse Technology Policy "strongly limits" what can be installed to handle membership data, as you sweepingly claim. The phrase "third-party software" is expressly defined as a term of art within the policy document (Section 3.11), so the provision of Section 4.9.3 only prohibits storing membership data in software "not approved for use on Church computers." But the Church policy of what is approved is published elsewhere in RKATS, and that policy says (my boldface emphasis):

When it comes to third-party software, the Church recommends using free software applications like OpenOffice when possible to keep costs down and to reduce the burden of keeping license agreement records. There is no prohibition against purchasing third-party applications or receiving donations of software, as long as the unit adheres to the license agreements and keeps physical copies of the license certificates in the clerk’s office. In the case of donated software, the donor must provide the software license certificate and confirmation that they have either uninstalled the software from or have never installed it on other computers.

When purchasing software, copies of the proof of purchase must be emailed to ITAssetManagement@ldschurch.org. Please include the unit number where the software will be used and the contact information of the individual who purchased it.

The software products listed below are optional, but have been used by many clerks. These products are free and do not require licenses. Other software products may be used as long as the guidelines above are followed.

That allows just about any software used for a gospel-related purpose, so long as it is properly licensed. That is really more permissive than the older policy that required stake presidents to approve each application installed.

The only major provision of the 2014 Meetinghouse Technology Policy that really does cut deeply into what units have been doing with membership data is Section 4.9.4 forbidding us to store this content in "cloud-based services." (There are a lot of Google Docs spreadsheets out there that are probably coloring outside the lines.) As far as the Google Maps Engine example being discussed in this thread, that provision is all we need to understand that it is out of bounds. Not because there is "third-party software" involved, but because "cloud-based services" are used.

There are three parts to this: What CHQ intended, the document they created, and how it's interpreted by local leaders. The last part depends on the individual leader's bias with regard to gray areas. Some avoid anything remotely gray. Others seem fine with darker shades.

As far as interpretations go, yours is no more authoritative then mine outside of our respective stakes.

If I understand your view of third party software, it is any that hasn't been properly licensed. But if that's the case, then why did CHQ add that paragraph about not putting information into third party software? Particularly if it's not supposed to be installed on a meetinghouse computer in the first place? The policy was updated less then 48 hours ago. So we may see/hear about this in the coming weeks. The prohibition on cloud services was there previously.

russellhltn wrote: If I understand your view of third party software, it is any that hasn't been properly licensed.

That is not my "view." That is the plain language of the formal definition of the term "third party software" within the Meetinghouse Technology Policy, read in conjunction with the RKATS article from which I quoted.

russellhltn wrote: But if that's the case, then why did CHQ add that paragraph about not putting information into third party software? Particularly if it's not supposed to be installed on a meetinghouse computer in the first place?

I can only know for sure what I read. As for your speculative question, apparently they did not want to compound the harm of installing pirated software with the harm of using it to load Church membership information. (Not much chance of importing Church finance information, since that cannot be exported from MLS in the first place.) I certainly have no reason to think they intended to include your own private, expansive meaning of "third party software" when they wrote a clear definition into the policy.

I might just as well ask speculatively why leaders would be allowed to export membership data as CSV files from MLS and lds.org if they are not allowed to use it in software.

russellhltn wrote: The policy was updated less then 48 hours ago. So we may see/hear about this in the coming weeks. The prohibition on cloud services was there previously.

The recent change to the policy affected where membership data came from, not where it could be stored.

If we do see more changes in the coming weeks, I will follow any updates in the policy. Meanwhile, I have no reason to follow forum folklore expanding the current policy.

RossEvans wrote:And on meetinghouse computers, the term "third-party software" continues to be expressly defined in that context -- "any computer software program that was not created by the Church or is not approved for use on Church computers." A separate RKATS provision defining what is allowed on Church computers is quite open-ended, and obviously allows spreadseets. So using membership data in local spreadsheets, either on Church computers or personal computers, is not prohibited per se.

The express language of section 3.11 that you quoted above uses the word "or". So it is quite clear from the policy document itself that the term "Third-Party software" includes even properly licensed software installed on the meetinghouse computer. The fact that a separate RKATS document (one not listed as "Policy") includes a conflicting reference to third party software doesn't change the express language of the actual policy. So looking at the policy document itself, the provisions of 4.9.3 would apply to any computer software program not created by the Church.

Of course local leaders will need to make the specific decisions, and work out those conflicts. But there is an argument that actual policy trumps a separate non-policy document. It's also entirely possible that the policy document is indeed self-consistent, but happens to use one definition of third party software for purposes of explaining what can be done with membership data, whereas the non-policy document uses a different definition of third party software for purposes of explaining what software can be put on a meetinghouse computer, which of course can be used for many purposes that do not include membership data.

Just some thoughts to consider....

aebrown wrote: The express language of section 3.11 that you quoted above uses the word "or". So it is quite clear from the policy document itself that the term "Third-Party software" includes even properly licensed software installed on the meetinghouse computer. The fact that a separate RKATS document (one not listed as "Policy") includes a conflicting reference to third party software doesn't change the express language of the actual policy. So looking at the policy document itself, the provisions of 4.9.3 would apply to any computer software program not created by the Church.

I don't think there is any conflict at all between the two policy documents, both of which are are published under the RKATS site hierarchy.

Within Section 4.9.3 of the Meetinghouse Technology Policy, the use of "third-party software" for membership data is prohibited. And what does that mean? It is explicitly defined within the Meetinghouse Technology Policy definitions section:

Any computer software program that was not created by the Church or is not approved for use on Church computers.

And what software is or is not "approved for use on Church computers?" For that, we must turn elsewhere in RKATS to the only current policy document we have that addresses that issue squarely. It states:

Office software not provided by default on Church computers

When it comes to third-party software, the Church recommends using free software applications like OpenOffice when possible to keep costs down and to reduce the burden of keeping license agreement records. There is no prohibition against purchasing third-party applications or receiving donations of software, as long as the unit adheres to the license agreements and keeps physical copies of the license certificates in the clerk’s office. In the case of donated software, the donor must provide the software license certificate and confirmation that they have either uninstalled the software from or have never installed it on other computers.

When purchasing software, copies of the proof of purchase must be emailed to ITAssetManagement@ldschurch.org. Please include the unit number where the software will be used and the contact information of the individual who purchased it.

The software products listed below are optional, but have been used by many clerks. These products are free and do not require licenses. Other software products may be used as long as the guidelines above are followed.

RossEvans wrote:

Any computer software program that was not created by the Church or is not approved for use on Church computers.

The problem is the word "or". It means everything not created by the church is third-party. "Or" can not subtract from that list. It can only add to it. It also makes the rest of the sentence pointless, but I've said before that I have issues about how things are worded. But if you're going to stick with the document as worded, that's what you get.

Now, if it said "and", then it would mean what you claim it means.

russellhltn wrote:

RossEvans wrote:

Any computer software program that was not created by the Church or is not approved for use on Church computers.

The problem is the word "or". It means everything not created by the church is third-party.

Huh?

So according to your reading, no software not created by the Church can contain membership data on the clerk's computer? That reading would make the second half of the "or" conjunction in Section 3.11 superfluous. It also would rule out anything that is allowed under the RKATS policy, even including Open Office spreadsheets, etc. So leaders can export membership data from MLS or lds.org by design, but can do nothing but parse it telepathically without software? Or we can create a spreadsheet report for the bishop or ward council, but never populate it with the names of members?

I read the "or" this way: There is a class of software that is prohibited to use for membership data. To be exempt from that prohibited definition, software can either be created by the Church, or it can be "approved for use on Church computers." And what is approved is defined elsewhere in RKATS: "Other software products may be used as long as the guidelines above are followed."

Aside from that RKATS section, we know of no current policy document that defines what is "approved for use on Church computers." The RKATS document contains an optional whitelist of various types of applications and utilities -- including but not limited to Open Office products -- that can be augmented by any other software that meets the guidelines. So the two documents must be read together to make sense.

I don't think the drafting of the policy would get the highest marks in a legal writing class, or even an English composition class. But there is not necessarily a conflict between the two policy documents unless you strain to create one with a nonsensical result. They can be read together in a commonsense way, and one supports the other.

RossEvans wrote:I don't think the drafting of the policy would get the highest marks in a legal writing class, or even an English composition class. But there is not necessarily a conflict between the two policy documents unless you strain to create one with a nonsensical result. They can be read together in a commonsense way, and one supports the other.

I think I'm winning you over to my side.

I really wonder about the scope part and the inclusion of the word "meetinghouse". It seem odd they'd include that word unless it was a shorthand for "wards, stakes, branches and missions functioning as stakes" and was not intended to be binding on other areas of the church such as offices.

Because it sure seems odd they'd have a policy that prohibits data being loaded in unapproved software (I think we're in agreement on that part), but it's acceptable to do so in one's home.

russellhltn wrote: I think I'm winning you over to my side.

Only to the extent that I agree the drafting is confusing. (Actually, I think the whole rollout of this new Meetinghouse Technology Policy has been handled rather clumsily all along. And this example is hardly the first confusing policy language ever promulgated in the tech area.)

But I am not at all persuaded that the way to resolve the inartful language is to declare that only Church-created software is allowed for use on Church computers. I just don't think leaders are supposed to consume CSV files -- properly exported, by design, from MLS or lds.org -- without any external software whatsoever. And I don't think we are supposed to ignore the second half of Section 3.11, which references "approved" software, or the RKATS policy language that explains what is approved.

RossEvans wrote:But I am not at all persuaded that the way to resolve the inartful language is to declare that only Church-created software is allowed for use on Church computers.

No one has ever said that. I suggested that one possible interpretation of 3.11 with 4.9.3 is that only Church-created software was allowed to access membership data. But no one has ever come close to saying that third-party software could not be used on Church computers for any purpose whatsoever.

aebrown wrote:

RossEvans wrote:But I am not at all persuaded that the way to resolve the inartful language is to declare that only Church-created software is allowed for use on Church computers.

No one has ever said that. I suggested that one possible interpretation of 3.11 with 4.9.3 is that only Church-created software was allowed to access membership data. But no one has ever come close to saying that third-party software could not be used on Church computers for any purpose whatsoever.

I left out the modifier "for membership data" in the above comment because I thought the context was understood among us by now. That was also my meaning.

(FWIW Section 3.11 does not specifically refer to membership data; it merely defines a term. It does happen that the only use of the defined term "third-party software" I can find within the Meetinghouse Technology Policy document is in Section 4.9.3. The term is used elsewhere in RKATS in a generalized context. The second half of 3.11 -- which russellhltn says we must ignore also refers to a generalized situation: "or is not approved for use on Church computers.")

Parsing 3.11, russellhltn says here:

The problem is the word "or". It means everything not created by the church is third-party. "Or" can not subtract from that list. It can only add to it. It also makes the rest of the sentence pointless ...

So in any case, with respect to membership data, you both are saying that one possible interpretation is that only Church-created software can access membership data. (russellhltn goes further, and argues that is the only possible interpretation.) I continue to reject that reading, because it leads to the nonsensical case that leaders can -- by design -- export membership data as CSV files from MLS and lds.org, but are then prohibited from reading those files in any software at all on the clerk's computer! That reading also requires us to ignore entirely the second part of Section 3.11, referring to "approved" software, even though there is a separate policy section elsewhere in RKATS that handily explains what software is approved. I cannot believe that was the authors' intent, however poorly they drafted Section 3.11's language.

RossEvans wrote:So in any case, with respect to membership data, you both are saying that one possible interpretation is that only Church-created software can access membership data. (russellhltn goes further, and argues that is the only possible interpretation.) I continue to reject that reading, because it leads to the nonsensical case that leaders can -- by design -- export membership data as CSV files from MLS and lds.org, but are then prohibited from reading those files in any software at all on the clerk's computer!

Considering that this updated document is less then a week old, what would you expect to happen? I think we'll find out in the months ahead if that was the intent or not.

russellhltn wrote:

RossEvans wrote:So in any case, with respect to membership data, you both are saying that one possible interpretation is that only Church-created software can access membership data. (russellhltn goes further, and argues that is the only possible interpretation.) I continue to reject that reading, because it leads to the nonsensical case that leaders can -- by design -- export membership data as CSV files from MLS and lds.org, but are then prohibited from reading those files in any software at all on the clerk's computer!

Considering that this updated document is less then a week old, what would you expect to happen? I think we'll find out in the months ahead if that was the intent or not.

I can't see how the update of the past week affected this particular issue at all. The effect of that update, so far as I can tell, was to add the phrase "whether obtained from within or outside of a meetinghouse" to Section 4.9.3. I think that includes, for example, data downloaded from lds.org, as well as data exported from MLS.

But while that modification affects the scope of where the data comes from, it has nothing to do with where storing the data is prohibited -- in "third-party software" on meetinghouse computers. The confusing language occurs in Section 3.11, defining that particular term of art -- language that has not changed one jot or tittle since the Meetinghouse Technology Policy was promulgated in January 2014, although the section has been renumbered from the original 3.10. So the issue you raise parsing the "or" conjunction in that definition section has persisted that long. (And you have been insisting since then that this policy constitutes a draconian crackdown on what software is allowed to be used locally for membership content.)

Probably the only reason this "third-party software" matter has not caused major issues for local unit leaders is that, due to the stealth rollout of the policy, few outside a tiny subset of this forum are even aware that the policy exists. Most who have read it, I suspect, adopt the same commonsense reading that I do, and continue to do whatever they have been doing with whatever non-Church software they have installed.

As for what I "expect to happen," I have no clue about what CHQ will do, or even if anyone there is aware of the issues you raise about the wording of Section 3.11. For my part, I expect to do nothing unless there is further clarification. We changed our processes in our unit to conform with the "cloud" restrictions in Section 4.9.4 some time ago, but I don't think we have made any changes to how data is handled on the clerk's computer due to the 2014 "third-party software" policy in Section 4.9.3. I still am not persuaded that we have to, because under the best commonsense reading of the language our software is compliant.

I called to our bishop's and stake's attention the existence of the new policy five months ago. We have been through a membership audit since then, and I know of no direction to stop putting membership information into external software installed on our unit computer, so long as confidential data is still protected per the handbook. We will just keep magnifying our callings.