NW Scheduler/Publisher - Updates, Support, and Suggestions

[trs]

With version 4.0.5 and Build 1449 of the NW Publisher App, non-publishers (persons without publisher status) are still not displaying properly. 

But the warning message about group features being removed in the second half of the year—and recommending the mobile version—has been removed.

Edited Monday at 11:39 AM by trs

[trs]

6 hours ago, Tortuga said:

I just noticed that the Cleaning Descriptions in NWS are not being included in the NWP Cleaning Duty. I altered the description and removed one group assignment, synced, replaced the group assignment and synced again, but the description did not show up in any of the NWP Cleaning assignments.  

4.0.5 and Build #1449 seem to solve the problem.

[trs]

7 hours ago, Tortuga said:

Has anyone used the new Custom Schedules feature? Any ideas or suggestions on what to use it for?

Yes, but it doesn't seem fully thought out. Tasks are displayed only under "My Duties" instead of under "Programs."

 

It would make sense if tasks could be assigned according to the normal program - possibly to the midweek or weekend meeting - and if it could also be set for each person who is allowed to do what.

 

Another issue is that there is no check whether the person already has other tasks, as in normal scheduling.

[foghorn]

8 hours ago, Tortuga said:

Has anyone used the new Custom Schedules feature? Any ideas or suggestions on what to use it for?

Yes - we have a family with no vehicle. We have an Excel schedule for 5 different families to take turns giving them a ride to the meeting. So, as a test, I created same schedule using this new feature. It shows up on the Duties list and in the Upcoming box on home page. And I assume I will get notifications also.

[Tortuga]

27 minutes ago, foghorn said:

Yes - we have a family with no vehicle. We have an Excel schedule for 5 different families to take turns giving them a ride to the meeting. So, as a test, I created same schedule using this new feature. It shows up on the Duties list and in the Upcoming box on home page. And I assume I will get notifications also.

I experimented with it last night and created a variety of schedules. I created one schedule with a date range, another with fixed dates. I created a schedule with multiple roles and descriptions. I intentionally scheduled myself several times to see if I would get duplicate assignments, and I did. It seems that it may be a useful tool for simple schedules. 

[Tortuga]

8 hours ago, Tortuga said:

I just noticed that the Cleaning Descriptions in NWS are not being included in the NWP Cleaning Duty. I altered the description and removed one group assignment, synced, replaced the group assignment and synced again, but the description did not show up in any of the NWP Cleaning assignments.  

The latest updates seem to correct this problem but created a new one. Now the Cleaning Duties assignment shows as a date range instead of a single date.

 

The updates didn't immediately correct the missing descriptions, the first time I removed one of the groups, sync, replace the group and sync again it still didn't show the description. The second time I did the same thing I noticed there was a Schedule Settings in the list of things to be synced and NWP showed the Cleaning Duty descriptions after that sync. 

[Tortuga]

2 hours ago, trs said:

 

Another issue is that there is no check whether the person already has other tasks, as in normal scheduling.

The Custom Schedule appears to be for events not related to the meetings, so they wont show up on the Meeting schedule.

 

I scheduled myself for a duty on the same night that I have a MWM assignment and NWS did not indicate any conflicts. That seems reasonable since the custom schedule duty doesn't have a specific time frame and doesn't conflict with the meeting.

 

I did notice that when I scheduled myself during an Away Period, the input field was red, indicating a conflict.

 

Edited Monday at 02:32 PM by Tortuga

[val86]

Hey, after the latest update, we lost all our field service reports.

 

I'm trying to restore data from before the update, but it's still not bringing the reports back.

 

Has anyone else had this issue and managed to fix it?

[Tortuga]

10 hours ago, Tortuga said:

Has anyone used the new Custom Schedules feature? Any ideas or suggestions on what to use it for?

BTW, it appears that the new feature is hidden by default when you update to NWS 8.1. You need to ask an administrator to give you view or edit access.

[Cruzer]

Perhaps I missed this, but is NWS Mobile not currently working? I keep seeing this message, "This version of NWS Mobile out of date. Please update to the latest version NWS Mobile. 8.1."

 

On the Google Play store, the latest version is still 8.0 and there is no update available.

[Tortuga]

7 minutes ago, Cruzer said:

Perhaps I missed this, but is NWS Mobile not currently working? I keep seeing this message, "This version of NWS Mobile out of date. Please update to the latest version NWS Mobile. 8.1."

 

On the Google Play store, the latest version is still 8.0 and there is no update available.

I have 8.0 #1018 en_US and it is working.

[trs]

9 minutes ago, Cruzer said:

Perhaps I missed this, but is NWS Mobile not currently working? I keep seeing this message, "This version of NWS Mobile out of date. Please update to the latest version NWS Mobile. 8.1."

 

On the Google Play store, the latest version is still 8.0 and there is no update available.

I think the NWS Mobile app will be available in the next few days. At first, it was important to solve the problems in the desktop version and the Publisher app.

I also can't connect the Mobile 8.0 #1018. 

Edited Monday at 04:55 PM by trs

[cdk.h5c]

1 hour ago, Cruzer said:

Perhaps I missed this, but is NWS Mobile not currently working? I keep seeing this message, "This version of NWS Mobile out of date. Please update to the latest version NWS Mobile. 8.1."

 

On the Google Play store, the latest version is still 8.0 and there is no update available.

[trs]

There is a new build of Scheduler Desktop: #1450. 

[drd217]

Why is my NW Publisher app all of a sudden in Spanish??

 

[trs]

8 hours ago, drd217 said:

Why is my NW Publisher app all of a sudden in Spanish??

 

Check inside the app

• Open Settings
• Look for “Language”
• Set it to your language

[Tortuga]

I have been playing with the NWS Custom Schedules and I noticed something interesting. When I am scheduled to do something on the same day as a meeting, the person icon will show up next to the meeting date on the Schedules page. I don't have any duties, assignments or group assignments for the next MWM but the person icon is there to show that I have a duty on the Custom Schedule that day.

[More4me2do]

I apologize if this post seems to leak through my frustration but the migration and updates of the NWS and NWP app seems to be not as smooth and error free as I have hoped for.

 

First of, our admins followed the instructions for updating to the "T". We experienced no problems and all those that would send data to the NWP App are on the latest versions 8.1 #1450. However my concern is the data in the NWS as we use this extensively for analyzing the congregation's ministry as well as the publishers in the FSGs.

 

Many of us invested a lot of time in populating the NWS with congregation specific data only to see some of it being wiped out by updates or whatever other gremlins there are in the bowels of the code plus tech challenged publishers. The territory data as available in previous versions is no longer the same and some of it has disappeared and now has lost its value in working the territories efficiently as you can see from the screenshots.

 

1. The publisher's name who worked the address is gone. This is important as now there is no way to check if the DNC or No Soliciting entries were correct and no way to help publishers with the status who worked addresses.

 

This is a territory I am working with the latest NWP app version.

 

2. There is no consistency of date entry as only the most recent worked addresses show a date entry when previously that was not the case. This is very important as we like to work our territories midweek and weekends.

 

See possible explanation for this at the end of my comments.

 

3. Yesterday I clicked the territory completed button on the NWP app of a publisher. There are dual entries in the NWS that are clearly in error.

 

 

 

4. In the past the territory servant would know when a territory was completed but now I can't find where to get that data without scrolling through territories and searching for dates. This is very important to us as we take a completed territory and export all NHs, No Trespassing, No Soliciting and Vacant addresses and give it to the telephone and letter writing groups.

 

The only explanation that I have for not listing the publisher's name who made the status changes that he is sill on the NWP app version 3.9.7. The status changes I made were always with the latest NWP app and also don't show the name. Since directing publishers that are out in the ministry is sometimes like herding cats, I am sure some did not have the latest version. Now how to create an error message for that situation I am not quite sure.

 

It is apparent that the Devs are spending exorbitant amount of time in maintaining a congregational tool that has risen to the status of being a necessity for congregation administration. As such, it is now a vital tool in fulfilling our commission and that is a heavy responsibility for the Devs.

 

Taking that into consideration, I would rather see a maintaining of its data integrity then moving to faster execution or developing nice to have features.

/OFF Soapbox

 

Edited 22 hours ago by More4me2do

[foghorn]

Amazon Fire Tablet: I have one sister with this tablet. The latest app version in Amazon App Store seems to ver 3.9, which won't load. Anyone know how to get 4.0?

[mikexkinsey]

15 hours ago, More4me2do said:

I apologize if this post seems to leak through my frustration but the migration and updates of the NWS and NWP app seems to be not as smooth and error free as I have hoped for.

 

First of, our admins followed the instructions for updating to the "T". We experienced no problems and all those that would send data to the NWP App are on the latest versions 8.1 #1450. However my concern is the data in the NWS as we use this extensively for analyzing the congregation's ministry as well as the publishers in the FSGs.

 

Many of us invested a lot of time in populating the NWS with congregation specific data only to see some of it being wiped out by updates or whatever other gremlins there are in the bowels of the code plus tech challenged publishers. The territory data as available in previous versions is no longer the same and some of it has disappeared and now has lost its value in working the territories efficiently as you can see from the screenshots.

 

1. The publisher's name who worked the address is gone. This is important as now there is no way to check if the DNC or No Soliciting entries were correct and no way to help publishers with the status who worked addresses.

 

This is a territory I am working with the latest NWP app version.

 

2. There is no consistency of date entry as only the most recent worked addresses show a date entry when previously that was not the case. This is very important as we like to work our territories midweek and weekends.

 

See possible explanation for this at the end of my comments.

 

3. Yesterday I clicked the territory completed button on the NWP app of a publisher. There are dual entries in the NWS that are clearly in error.

 

 

 

4. In the past the territory servant would know when a territory was completed but now I can't find where to get that data without scrolling through territories and searching for dates. This is very important to us as we take a completed territory and export all NHs, No Trespassing, No Soliciting and Vacant addresses and give it to the telephone and letter writing groups.

 

The only explanation that I have for not listing the publisher's name who made the status changes that he is sill on the NWP app version 3.9.7. The status changes I made were always with the latest NWP app and also don't show the name. Since directing publishers that are out in the ministry is sometimes like herding cats, I am sure some did not have the latest version. Now how to create an error message for that situation I am not quite sure.

 

It is apparent that the Devs are spending exorbitant amount of time in maintaining a congregational tool that has risen to the status of being a necessity for congregation administration. As such, it is now a vital tool in fulfilling our commission and that is a heavy responsibility for the Devs.

 

Taking that into consideration, I would rather see a maintaining of its data integrity then moving to faster execution or developing nice to have features.

/OFF Soapbox

 

@More4me2do I agree with you, this update was a rough one.  I really appreciate the significant detail and explanation of your observations and how/why we use this tool that has become so integral in our preaching activity (1 Cor 14:40).  Have you shared this detail with the Devs?  I hope so.  Our dear brothers/sisters down under, should have the opportunity to  include your feedback when working on the fixes, short term and long term (future updates).  If you share with them, it might get better; if you don't it probably will not, at least any time soon (Pr 11:14, 15:22).

 

YB, Mike

[Jonathan1]

18 hours ago, More4me2do said:

1. The publisher's name who worked the address is gone. This is important as now there is no way to check if the DNC or No Soliciting entries were correct and no way to help publishers with the status who worked addresses.

 

 

One thing that immediately stands out to me is the loss of the publisher name connected to territory activity. At first glance this may seem like a small issue, but in practice it is actually a serious data integrity problem.

 

Territory information is not only used to track whether an address was worked. It is also historical ministry data that helps the territory servant and elders understand what happened at an address and why certain statuses were assigned.

Once the publisher name disappears, all context is lost. The status remains, but the history behind it is gone.

 

From a technical perspective, this usually happens when systems overwrite the current territory state during synchronization instead of preserving the original event that created the change. In other words, the system remembers the latest status, but no longer remembers who created it.

 

Personally, I believe territory systems should preserve a complete historical trail for every address update. Without that history, territory data gradually becomes less reliable over time.

 

This is one of the reasons why Baruch is being designed around immutable history/events rather than simply overwriting the latest state. Every territory action remains traceable, while still respecting privacy principles by avoiding unnecessary centralized personal data storage.

Good territory management is not only about synchronization. It is about preserving trust in the accuracy and accountability of the data.

[Jonathan1]

18 hours ago, More4me2do said:

2. There is no consistency of date entry as only the most recent worked addresses show a date entry when previously that was not the case. This is very important as we like to work our territories midweek and weekends.

 

 

In the screenshots, some addresses only show entries such as “Sat AM” or “Wed AM,” while other addresses display full dates. Previously, the territory history appeared to be much more consistent. That inconsistency may seem cosmetic at first, but in reality it directly affects how efficiently territories can be worked.

 

Many congregations intentionally work territories at different times. Because of that, accurate historical date information becomes very valuable. It helps publishers avoid repeatedly calling at the same ineffective time and makes territory work more strategic and organized.

 

When date information becomes inconsistent or partially disappears, the territory data loses analytical value. It stops being reliable ministry history and becomes little more than fragmented notes.

 

From a technical perspective, this often happens when different app versions or synchronization models store date information differently. One client may save a structured timestamp, while another only saves a simplified “time slot” value such as “Sat AM.” During synchronization or migration, parts of the metadata may then be overwritten or lost.

 

This is another reason why I believe territory systems should preserve immutable historical events instead of only storing the latest visible state. Every territory action should contain the exact timestamp, the publisher involved, type of activity.

 

In Baruch, territory history is designed to remain historically consistent over time, even when synchronization occurs between devices or app versions. The goal is not simply to display territory data, but to preserve meaningful ministry history that congregations can continue to rely on years later.

[Jonathan1]

18 hours ago, More4me2do said:

3. Yesterday I clicked the territory completed button on the NWP app of a publisher. There are dual entries in the NWS that are clearly in error.

 

 

A territory completion is not a minor action. In many congregations it is the trigger for several follow-up processes. Because of that, duplicate completion records can quickly create confusion and reduce trust in the accuracy of the data.

 

What likely happened here is that the completion action was processed more than once during synchronization. This can occur when:

• a mobile device retries a request after a slow connection

• synchronization temporarily fails and resends the same action

• different clients process the same update independently

• the server cannot distinguish between a new event and a repeated one

In NWS, synchronization is state-based: “Here is the latest territory state.”

But actions like “territory completed” are actually events, and events should only be processed once.

That way, if synchronization retries occur, the system can recognize:
“This event was already processed.”

 

Personally, I think this highlights an important shift that congregation software must make. Once mobile apps and synchronization are involved, the architecture must be designed around reliability and event integrity first — not just convenience features.

 

In Baruch, territory actions are being designed as immutable events with unique identifiers and synchronization tracking. This allows duplicate sync attempts to be safely ignored while preserving a complete historical audit trail.

For congregation administration, reliability is far more important than adding more features. If brothers cannot fully trust the data, the software eventually creates more work instead of reducing it.

[Jonathan1]

18 hours ago, More4me2do said:

4. In the past the territory servant would know when a territory was completed but now I can't find where to get that data without scrolling through territories and searching for dates. This is very important to us as we take a completed territory and export all NHs, No Trespassing, No Soliciting and Vacant addresses and give it to the telephone and letter writing groups.

 

 

Territory management is not just about storing addresses, but about supporting real congregation workflows.

In the past, the territory servant could immediately see when a territory was completed. Now, according to the screenshots and comments, that information seems to be buried inside individual territory history, forcing brothers to manually scroll through territories and search for dates.

 

That may sound like a small usability issue, but operationally it becomes a major problem.

In many congregations, a completed territory triggers additional ministry work, like extracting Not Homes or identifying vacant or difficult addresses for future follow-up

So the “territory completed” action is not simply informational. It is actually a workflow event that other ministry activities depend on.

 

When users can no longer easily query or filter that information, the software shifts work back onto the territory servant manually. Instead of helping organize the ministry, the brothers are forced to search through raw territory history themselves.

 

From a design perspective, this usually happens when systems focus mainly on displaying current territory state rather than exposing meaningful operational events in a searchable way.

 

Good territory systems should allow brothers to instantly answer questions such as:

• Which territories were completed this week?

• Which territories contain Not Homes?

• Which addresses need telephone follow-up?

• Which territories have not been worked recently?

• Which territories were completed on weekends versus midweek?

That requires more than simple lists or static records. It requires queryable historical events and workflow-aware design.

 

The goal of Baruch is that territory servants should never need to “hunt for information.” The software should help surface the information needed for the next ministry step quickly and clearly.

To me, that is where congregation software creates real value: not by storing more data, but by reducing administrative friction and helping brothers focus on the ministry itself.

[carlos]

20 hours ago, More4me2do said:

I apologize if this post seems to leak through my frustration but the migration and updates of the NWS and NWP app seems to be not as smooth and error free as I have hoped for.

 

James, thank you for sharing your experience. We feel your pain as many of us have faced similar issues.

But you understand that there isn't anything we can do about it other than listening, right? It would be a good idea to send those screenshots and explanations to the developers so that they can fix whatever is not working well.