One Instance, Two Divisions, Conflicting Mandatory Fields
A utility contractor operates electricity and plumbing divisions on a single Oracle Field Service instance. The instance supports 850 field resources, 22 activity types, 140 properties, and six shared work zones. Electricity work orders must capture meter serial number and voltage before an activity can be completed; plumbing work orders must capture pipe material and water pressure. Operations wants one instance so that resources, work zones, and reporting remain shared across divisions. A consultant has proposed cloning the instance per division and duplicating routing configuration. In the current pilot, all 140 properties appear on every activity screen, technicians complain about clutter, and 18% of completed activities are missing at least one division-specific value because those properties are optional at the activity type level. Electricity also requires the meter serial number to be exactly 12 alphanumeric characters and unique per premises. The pilot has 90 days before rollout.
1. Recommend the configuration model for division-specific fields, screens, and mandatory rules without splitting the instance. Justify the choice against the consultant's cloning proposal.
Read the worked answer
Keep one instance. The divisions share resources, work zones, routing, and reporting, so cloning would duplicate routing plans and work zones and would prevent a single resource pool from covering both lines of business. Model the divisions with activity types: electricity activity types and plumbing activity types. Attach division-specific properties to the relevant activity types, place them in property groups, and use property display conditions so the electricity group appears only on electricity activities and the plumbing group only on plumbing activities. Set the required flag at the activity-type level, not globally; a global mandatory flag would block every activity. Use work order types only for header-level data that does not vary by technician task. Keep shared properties global and minimal. If a property is needed for reporting across both divisions, keep the same property key and control visibility by activity type. This preserves one routing configuration, one resource pool, and one reporting model. Cloning would also create a second integration target and double the administration of 140 properties and 22 activity types.
2. Explain how to enforce the 12-character alphanumeric format and uniqueness per premises, and identify the limits of native property validation.
Read the worked answer
Use a property validation rule on the meter serial property with an anchored regular expression such as ^[A-Za-z0-9]{12}$ and an error message that tells the technician the exact format. Mark the property required on the electricity activity types. Normalize case at entry if the business treats serials as case-insensitive; otherwise document that case is significant. Native OFS property validation is good at format, length, and pattern, but it does not reliably enforce cross-activity uniqueness per premises. Do not promise that a unique checkbox alone will prevent duplicates. Enforce uniqueness at the integration boundary: when an activity is created or updated, a message scenario or plugin queries the premises/serial registry or the OFS API for an existing activity with the same premises and serial. Reject or quarantine the transaction with a clear error. Also validate in the source system if it is the system of record. Add a daily exception report of duplicates so the pilot can catch gaps before rollout.
3. The shared instance must still route only qualified technicians. What routing and capacity objects would you configure, and what would you test?
Read the worked answer
Use work skills Electricity and Plumbing and assign them to the appropriate resources; a resource can hold both if cross-trained. Build routing plans or routing-plan filters that match activity type to required skill, and use capacity categories for the divisions if the quotas differ. Keep the six work zones shared, but verify that each zone has enough qualified resources; otherwise the routing engine will leave work unassigned or travel excessive. Use resource pools for cross-trained resources only if dispatchers are allowed to move work between divisions. Test with a sample of 100 activities per division: confirm electricity activities never go to plumbing-only resources, confirm the required property group appears, confirm completion is blocked when the serial is missing, and confirm routing does not violate the skill match. Also test a cross-trained resource receiving both types and check that quota consumption is attributed to the right capacity category. Review unassigned activities daily during the pilot.