I confess I'm still trying to understand why I would want to create a Worksite network, instead of a Division network. That is, if the work location is not shared by multiple employers and the network you're creating is a child of an Organization/Employer, University, or Program network.

I read there are certain disadvantages to Worksite networks. For example, users are allowed to have an account with only one Worksite network. The "Show All Members" function is not available to Worksite networks. And Emergency Ride Home usage reports are not available to Worksite networks.

True, a Worksite network can be created as even a child of a State network. Division networks can only be children of an Organization/Employer, University, or Program network.

Worksites have physical addresses. Divisions do not. Then again, Organization/Employer's don't have physical addresses, either. You want a physical address? Set up a "Location." Locations may be set up within an Organization/Employer network, School, and University networks.

I think Division network is the better choice than Worksite network, as the child of an Organization/Employer, University, or Program network.

You can configure a Division network with unique display text, on the parent network, such that the child Division network would be called a “department,” “unit,” “branch,” or “office” when displayed to commuters in the parent network.

If users register with a network that has established Divisions, they will be invited to select a Division from a drop-down menu. Users can also join a Division network by going to their Profile. Users can opt to join or leave the Division network.

Given all this - and again, assuming I am setting up a child network where there's only one employer - why would I want to create a Worksite network, when I can create a "Division" network instead?

Views: 50

Reply to This

Replies to This Discussion

The different types of networks are a toolkit for solving different business cases and in many cases interchangeable. That said, there are certain types of networks that are more suited to a particular configuration. 

If you do perform or would like to perform administrative functions that affect users in a location such as communication, incentives or reporting - worksite network would be of interest. When users sign up and enter their work location or when they change their work location - worksite association is handled for them. So it works naturally for location based scenarios.
Divisions are a newer type of network, interesting for many scenarios and also a candidate for location based configuration. However, it is important to note that a user can be part of only one division belonging to one network. This means if the network uses divisions for campus sites or worksite locations - the network will not be able to use divisions for departments within the organization. Therefore it is important to consider the longer term configuration for the network - will they need to perform administrative functions based on some other groupings such as departments or teams or staff/student/faculty type of role. If they do, then it may be useful to reserve the divisions for that grouping and use worksite networks for its locations. A network could always use both worksite networks and division networks.

Thank you, Amol. This is useful information.

I continue to be interested in the details which differentiate Worksite from Division networks.

I had not realized that both these networks share a common detail: With each, users can only belong to one. That is to say, a user cannot belong to more than one Worksite network or more than one Division network. With respect to this detail, there seems to be no difference between Worksite and Division. This is important for some kinds of University and Employer/Organization networks, I think, where there are significant numbers of commuters who may commute to one location on one day, but a different location on another day. It sounds as though either Worksite or Division networks would pose a problem to those kinds of "cross-location" commuters.

Worksite networks can be "shared" by more than one employer. That seems a unique characteristic for Worksite networks and not Division networks.

If a network were set up for a school district - not a SchoolPool, but a network for teachers and staffs at the district - might there be a problem in accommodating needs of staffs that circulate among individual school locations (nurses, certain kinds of teachers, etc.)? If each school were it's own Division or Worksite, wouldn't that pose a problem for these cross-location commuters? On the one hand, it makes sense to have each school as its own Division or Worksite (Amol, which type of network do you think is best and why?), because that would allow each school to be administrated separately from another. If I'm a band teacher who rotates through a few different schools, though, won't I have trouble with the fact I cannot be associated with more than one Division or Worksite?

If I created an Employer/Organization network for an entire school district, and used either Divisions or Worksites for each school, should I also create network Locations for each school? That way, those cross-location commuters would be members of the parent Employer/Organization network only and would use Locations to identify specific schools within the district. Is that a useful solution?

Thanks, in advance, for your thoughts.

University and Employer/Organization networks, I think, where there are significant numbers of commuters who may commute to one location on one day, but a different location on another day. It sounds as though either Worksite or Division networks would pose a problem to those kinds of "cross-location" commuters.

I can't see why a University with the above situation would want a worksite location or division location for their campus. Those network types exist - but they are optional. So each employer/university network creates a hierarchy that fits their needs.  As we've discussed in a separate post, network locations might be a way to go here for the campus locations. In that case the university could use divisions for role - staff/student. The same strategy could be considered for school networks.

There were many inputs gathered during the initial project cycle where we learnt  from a broad set of stakeholders that network associations have multiple implications for varied business needs. With the networks design in place, we've optimized for the majority cases such as automatic associations based on locations. I'm sure we haven't been able to  optimize every possible scenario  in the product and perhaps the band teacher who rotates in different schools would need to use some workaround. 

If I created an Employer/Organization network for an entire school district, and used either Divisions or Worksites for each school, should I also create network Locations for each school? That way, those cross-location commuters would be members of the parent Employer/Organization network only and would use Locations to identify specific schools within the district. Is that a useful solution?

Personally, I believe a cleaner implementation is using a school network to designate a school. The schools in their network could use network locations and parents would be using network locations in that case (not worksites or divisions).

If I created an Employer/Organization network for an entire school district, and used either Divisions or Worksites for each school, should I also create network Locations for each school? That way, those cross-location commuters would be members of the parent Employer/Organization network only and would use Locations to identify specific schools within the district. Is that a useful solution?

I want to point out that my original scenario had no network being created to accommodate the needs of parents bringing their children to school. My scenario only dealt with the needs of faculty and staff commuters. Therefore, I believe no School network type would be used. My understanding is that a School network type is appropriate only to accommodate the special needs of parents.

Please correct me, though, if I am wrong.

If I am correct - School network type only for parents and not school faculty and staff - then what is the best answer to the questions I posed: Should network Locations be created for each school, to accommodate the needs of cross-location commuters?

The iCarpool manuals seem to indicate that a Worksite can be a child of a regional network. However, I cannot see how this can be done.

The manual entitled "Chapter 1: Before You Begin" reads, "Worksite networks may be established by administrators of Organization/Employer and University networks, as well as State, Regional/Agency, County, Jurisdiction/City and TMA administrators.'

But the Network Administration Manual reads, "Worksites and division networks may have Employers and Universities as parent networks."

I can find no link to "Add Worksite" from a State, Regional or Division network. However, I can see that Jurisdiction/City, TMA, and Organization/Employer networks can add Worksites.

Is the Chapter 1 manual incorrect?

State, Regional/Agency, County networks can establish worksites by proxy managing lower level networks that can create a worksite. Perhaps that clarification could be added - it might be good feedback to Amy's team for them to consider. Division networks are at the lowest level in the hierarchy and are not able to create other networks. 

I understand now.

While there are limits to the kinds of administrators who can initially create a Worksite network, once it is created, a Worksite network can have as its parent network(s) many more kinds of networks.

Worksites can only be created by administrators of Jurisdiction/City, TMA, Organization/Employer, and University networks.

But, once created, Worksite networks can have as parents State, County, Regional/Agency, TMA, Jurisdiction/City, Organization/Employer, and University networks.

And, a single Worksite network can be associated with more than one parent network.

Thanks.

RSS

© 2024   Created by Stan Suchan.   Powered by

Badges  |  Report an Issue  |  Terms of Service