Address Book for BC

[aholstrup]

Let's create an addressbook for Business Central!
Right now users have to manually type email addresses into the email editor. With this addressbook we will allow users to select addresses by either:

1. Selecting an email from the list of "Suggested Contacts"
2. Allowing users to access existing entities with email addresses in BC like Contact, Customer, Vendor, Employee etc. to

This PR is a rough draft, but provides an overview of our suggested approach.
Let us know what you think! :)

[ghost]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

❌ aholstrup sign now
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[JesperSchulz]

I know this is a very early PR and I will hence stop my review before I even begin ;-) But you could fix the naming already.
Looking forward to get tests added too.

[JesperSchulz]

Should be Address Book. Please fix everywhere.

[JesperSchulz]

Classification pending.

[JesperSchulz]

I wonder if we should make a more generic address book, that is capable of returning full addresses, rather than just email addresses? Then the address book could get more widely used.

[hhfiddelke]

One question:
What is the usage case of this Address- Book?
Where should it be used?

[JesperSchulz]

Initially, the "address book" was just an email address picker for the email editor. Now we're considering to make it a little more general purpose. It won't be a module which actually stores addresses in a unified way throughout Business Central - that would blow the budget of this initiative. Much more, this address book will be capable of browsing through Business Central entities, pick out address details and return the ones selected. Does that make sense? Uptake in our case will initially still be in the Email Editor. The user can drill down on "To:", "BC:" or "BCC", the address book will open, the user selects entities and the address book returns the emails (and more) of the selected entities. But one could also imagine this being used in other places!

[hhfiddelke]

Interesting idea easpecially for CC and BC addresses, which might be addresses not in BC.
On the other side is it very difficult to select a Email-Address without knowing the context. is not very interesting to know that there is a Mr. Smith with a mail-adress "fadfaKJGAksjghdbaduz12dfg@ebay.com" (no real address but as cryptic as eBay or Amazon addresses are). you need the context from the customer because you want to send him a mail as Customer because of a question. Same for vendors.
So in most cases we will need the context that delivers the mail-address of the destination, where would not be the requirement for an address- book.
I would prefer to have a mailing feature that allows to send mails and select mail addresses from a filtered context.

And we have an address- book in BC it is named Contact.

I don't think that we need Outlook 0.5 in BC

[quadfin]

Hi @JesperSchulz, per our previous conversation on this.. It makes sense to start off simple with an address browser of sorts that harvests and presents the email addresses from the document, customer/vendor and related contact cards for the record being sent. It should be rather generic, utilize the built-in email relationship property, and be extensible to allow addition of other address repositories. I haven't had a chance yet to take a look at 18.3 but will do asap. Will comment further when I have more insight.

[hhfiddelke]

@quadfin. Same question to you:
Where do you need the address book and not the customer, vendor, or contact, or a specific address (sales, accounting,.. ) from these entries?

[GiorgosPa]

@hhfiddelke This is not about reimplementing Outlook nor replacing the Contact page. This is simple Business Central becoming smarter and serve you the right information exactly where you need it. Business Central already knows the document an email is related, it also knows the entity behind this document Customer/Vendor and the Contacts behind this entity. I find it very useful to navigate this graph and serve you the addresses you most likely want to use.

Here is a neat demo of what @quadfin wants to introduce into the product.

[hhfiddelke]

Agree, so we need the possibility to select addresses that are available from context like contact, customer, vendor, document, local mail addresses.
That's O.K., but i hate to store redundant data in a separate table, that's in most cases the cause for bugs, because they are often not correctly updated after modification.

[quadfin]

@hhfiddelke, my current understanding of this effort is that it aims to provide better access to information (email addresses) that already exists in various stores (customer/vendor, contact, document, ...) but is not readily accessible from the email dialog. Presently, for example, if you wish to add an address from a related contact card then you must navigate the system to find that contact, copy the address, then navigate back and paste it into the email dialog recipient field. That's a pain. This effort would simplify that process. The first rev of this 'Address Book' would not implement storage of new email addresses, though it could be extended to do so in an extension app. Hope that helps.

[hhfiddelke]

Agree, but why are you sending this e-mail? Just for fun?

[quadfin]

Sorry, I don’t understand your response. From: Hans H. Fiddelke ***@***.***> Sent: Wednesday, July 14, 2021 7:21 AM To: microsoft/ALAppExtensions ***@***.***> Cc: quadfin ***@***.***>; Mention ***@***.***> Subject: Re: [microsoft/ALAppExtensions] Address Book for BC (#13165) Agree, but why are you sending this e-mail? Just for fun? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13165 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHMHI23CVJCFKOILPBHX4YTTXWML7ANCNFSM5ADDM27A> . <https://github.com/notifications/beacon/AHMHI23G5HJZBSDAJHSDXZTTXWML7A5CNFSM5ADDM27KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGRZL3LY.gif>

[hhfiddelke]

In my opinion it has a cause why you are sending an e-mail from BC, and not from Outlook.
So what is the cause why you might want to send a mail from BC?

[quadfin]

As an independent (not Microsoft) ISV developer it’s not my place to talk up (or down) the merits of email in Business Central. Having said that, my two cents.. A common task in BC is the sending of documents to customers/vendors – e.g., Posted Sales Invoice, Purchase Order, etc. Hence the need for an email feature. A current difficulty is getting the right address(es) onto the email. Hence the need for this Address Book feature. From: Hans H. Fiddelke ***@***.***> Sent: Wednesday, July 14, 2021 7:58 AM To: microsoft/ALAppExtensions ***@***.***> Cc: quadfin ***@***.***>; Mention ***@***.***> Subject: Re: [microsoft/ALAppExtensions] Address Book for BC (#13165) In my opinion it has a cause why you are sending an e-mail from BC, and not from Outlook. So what is the cause why you might want to send a mail from BC? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#13165 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHMHI25GYJO3Z3LEAUUWBP3TXWQYHANCNFSM5ADDM27A> . <https://github.com/notifications/beacon/AHMHI23YL4GWCI3BBUUDEQLTXWQYHA5CNFSM5ADDM27KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGRZTHWI.gif>

[hhfiddelke]

So, now i understand a little bit more. It seems to be a little also my problem, because we do not have this problem in our NAV- Solution.
Our documents have up to four e- mail- addresses, Sell-To, Bill-To, Ship-To and Accounting, and where to send to is decided by the sent document type.
I think this way is much easier for a user, because he/she/it does not need to search for the addresses in most cases when sending a document. But i agree there should be a way to add additional email- addresses first from the context (customers contacts, internal sales people, internal users,..) and then from all. But then you have the problem to select the right one from all available.
EDIT: I do not want to search for an email- address for every document i have to mail to a customer or vendor. The document has to know who is the default recipient.

[aholstrup]

Thank for the feedback @hhfiddelke and @quadfin. As mentioned in previous comments, this address book will simply give users the possibility to look up email addresses of other people, that might need to receive a given email. We're excited to hopefully ship this feature very soon. If you have any feedback to the implementation, we are of course happy to hear that as well :)

[JesperSchulz]

Final release version is released with 19.3. Bit will get updated with 19.3 push.