- This topic has 9 replies, 4 voices, and was last updated 2 hours, 48 minutes ago by Gary Johnson.
8 February 2021 at 12:58 pm #265Charles Moscato
Having now reviewed the Referral Spec, and having watched last weeks seminar, there’s a discrepancy around whether we are going to receive the actual customer email address. Within the Q&A of the seminar, it was stated that we would be receiving both the Customer email address, as well as the DBYD email response within the .xml. However, within the Referral Spec, it only states the customer email field which relates to the DBYD email relay response. Can you please clarify whether we’ll be receiving the actual customer email address? Thanks.+210 February 2021 at 2:02 pm #266Bruce.k.
Also reviewed the spec and have concerns we will not be provided with the customers email address and forced to use the relay response for all communications back to our customers including the initial response and post DBYD responses we have on specific inquiries that affect particular assets. There are potential privacy issues here for post processes where the only way we can easily email the customer is via a 3rd party or having to manually contact the customer via phone and record it separately from the initial DBYD inquiry, encroachment or other process history
Discussions in the webinar clearly indicated we would receive both the relay response email and the customers email.
Will need this clarified please.
011 February 2021 at 12:00 pm #270siteadmin
- This reply was modified 2 weeks, 6 days ago by Bruce.k..
Hi … thanks for your questions. Please check out the “Communicating with the Enquirer” section of the Q+A from the webinar. Hopefully this clears things up for you.011 February 2021 at 12:12 pm #271Charles Moscato
The actual response within the Q+A section states "enquirer’s personal email address can still be found via the Asset Owner’s web application". However, without this information supplied via the .xml, how are we to identify the customer's email within our internal web application. Still unclear.+111 February 2021 at 12:19 pm #272Bruce.k.
Hi Charles, I’ve got exactly the same concerns. Feel free to reach out to me for discussion at firstname.lastname@example.org February 2021 at 8:19 am #307Gary Johnson
Thanks for your questions. The footer of the referral email (text format) will include a notice similar to this: –
Notice: Replies to this email will be forwarded to the enquirer via Dial Before You Dig. Should you wish to advise Dial Before You Dig of any issues with this enquiry, please call 1100. Responses to this referral should be sent to the “EMAIL ADDRESS” specified above which is the relayed address for Gary Johnson (email@example.com). Please reference sequence number 600003970 in all correspondence.
This minimises change to the structured part of the email by placing the additional information in the footer section.
Gary023 February 2021 at 9:11 am #308Bruce.k.
Thanks Gary however this still doesn’t address the issue.
DBYD is missing the concerns from the utility here. As an asset owner we need to have the ability to import the customers email address into our existing DBYD systems which then support secondary critical processes across both electric and gas infrastructure. Its of zero value having the customers email address sitting within a footer of an email referral notification.
The proposal above assumes that all utilities will be receiving an email notification of the referral and imported into our DBYD systems. This assumption is incorrect as there are multiple methods utilised by the asset owners to import the referral information including the structured text email, XML, GML, and web services polling directly to DBYD.
The explanation of “minimises change to the structured email” isn’t correct as DBYD are already making changes to the email by adding and removing existing fields we have today and including additional values. As a utility we need the customers email to be imported into our system from any of the available methods – Email, XML, Web Services and being involved in applications development for the last 20 years, I know its not a big deal to do….even at this stage of development. This could easily be modified to meet the Utilities requirement in under 1 hour.+123 February 2021 at 9:55 am #309Charles Moscato
Thanks Gary, but I agree with Bruce’s points raised. Having the email address within an email footer will not be as easy to extract and update into our database. YVW’s internal process is to capture the DBYD submitted jobs within our internal Database, which overlays the .GML DBYD geometry information and associated customer details within our corporate GIS for greater awareness of DBYD jobs/location. Where concerns are raised with these DBYD requests, we have a simple mechanism to reach out via the email address. With the structural change in removing the FAX NUMBER field from the XML / Email content, couldn’t this be renamed to CUSTOMER EMAIL (separate to the EMAIL ADDRESS – Relay address requirement)?023 February 2021 at 10:17 am #312Bruce.k.
The solution is relatively easy.
- Leave the existing “CustomersEmail” field as it is today.
- Create a new “DBYDRelayEmail” field similar to Charles response above.
Its simple to configure our DBYD systems to utilise this relay address without affecting all down stream apps and processes that utilise the existing “CustomerEmail” field. If you were to continue with the current approach then it would be significantly more development work for the utility to migrate all historical customer email address’s out and into a new field along with further development and testing of secondary systems to see the customer email.02 March 2021 at 4:29 pm #359Gary Johnson
Please refer to the updated Referral Specification documents and examples.
A new field has been added to the email body, the XML attachment and the web hook payload for the user’s registered email address. This contains the email address entered by the user on their profile.
Responses should still be sent to the relay email address supplied. This address can be used for matching to an enquiry user’s history or for direct contact bypassing the relay service.0
- You must be logged in to reply to this topic.