[Outlook] Allow setting user signature

[claell]

I'll create a mirror issue for https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/allow-setting-user-signature-in-outlook-from-add-in/idi-p/3596992 here, as that forum seems to be pretty much dead right now (almost no reaction, no tasks being worked on).

Coming from https://stackoverflow.com/questions/57551608/access-user-signatures-from-within-outlook-add-in.

This functionality would really help with my Add-in development. It is a bit sad to see that the API is rather limited, right now. Should I switch to the old (not web based) Add-ins instead?

[samantharamon]

Hi, @claell. Thank you for submitting your request to Tech Community and for your feedback on your experience. I'm sorry to hear about your frustration with the process. While Tech Community is currently the correct platform to submit your features requests and ideas, please be advised that our team is investigating ways to better engage with the community. If you get a chance, I highly recommend watching the recent update on this during this month's Office Add-ins community call and providing feedback via the suggested channels in the video.

Regarding signatures in Outlook, we have an Office Add-ins sample that uses event-based activation to set signatures that may assist you with the development of your add-in.

[claell]

Thanks, @samantharamon, for the reply. I am aware of that sample, that you linked. Unfortunately, that is about inserting a custom signature from within the Add-in. I am looking for a way to select an existing user signature from the Add-in. So the signature itself comes from Outlook, not from the Add-in.

[claell]

Also, thanks for the reference to the community call, where this topic was discussed. Nice to see that this is on your agenda. I agree that changing to GitHub entirely will likely hugely improve things. Developers are used to it, so there is no problem with usability on that side, I guess. Integrating this into the normal development flow without too many unnecessary platforms in between is a good thing!

You can also look at GitLab, as an example. They already do a pretty similar thing for their product.

[claell]

Forgot to ping @lindalu-MSFT

[lindalu-MSFT]

@claell Thanks for pinging me. Do you mind if I convert this to a Discussion and we can test this out?

[claell]

In my experience, both, issues and discussions have their downsides. From a user perspective, using issues seems more straightforward. Of course, the backlog will get huge, but that is nothing to feel worried about, imho.

I think I know one other project that switched to discussions for a short time and then back to issues again. Not sure what the reasons were, though. Feel free to convert this issue, if you want to test out discussions, I am open to that.

My goal is to get this functionality, I don't care about the how.

[samantharamon]

Thanks, @samantharamon, for the reply. I am aware of that sample, that you linked. Unfortunately, that is about inserting a custom signature from within the Add-in. I am looking for a way to select an existing user signature from the Add-in. So the signature itself comes from Outlook, not from the Add-in.

Thanks, @claell. I've added @JuaneloJuanelo to this post for visibility. When you get a chance, could you provide us with more detail about your scenario for getting and selecting user signatures from Outlook?

[claell]

Thanks, @samantharamon. ~I have explained a scenario where I need this functionality for in #2767.~ Basically, the current use case I am thinking of is creating an Add-in that can force the reply to use HTML format and also then uses the HTML standard signature. ~See the referenced issue for more details on it.~

That also involves changing the signature back to the HTML one after changing the bodyType.

See https://www.howto-outlook.com/howto/replyinhtml.htm#macrocode for reference. This is apparently doable with a macro, and probably also with the old Add-in API.

I was hoping to be able to do it with the new Add-in system, though. That seems to be the future, and I don't really want to invest time in legacy things.

[JuaneloJuanelo]

@claell sorry for the delay on this somehow we dropped the ball on this case.

I want to make sure I understand your requirement, from our perspective i think you should be covered to implement a Web Add-in instead of a COM Add-in.

I think you are raising 2 different but related issues.

1. Inserting an existing native signature. This is not supported in the API. We support inserting a signature (via setSingature API )that can be either HTML or plain text. As a developer you can check the current composeType [to see if the user chose to compose in RIch Text or plain text] . That can give you 100% of whats supported natively and even more, with the help of event based add-ins you can modify this singature in real time, for example if external recipients are added you can replace the singature intended for external audiences (this is not supported natively.) can you please explain why this is not a solution for your scenario?

2. Setting the compose type. This is 100% related to your previous item (2767) today we don't support setting the compose mode and change it from plain text to rich text. This is a bit controversial because this is an end-user explicit action. THats why in the platform we believe that add-ins should adhere to what the user selected rather than forcing to change to a specific format. DO you need an event to switch to rich or plain text singature if the user moves from one to the other compose mode?

Thanks so much for your help. I will tag a needs feedback from author.

[claell]

I find it interesting that you can leave an issue unanswered for so long, while the bot requires a reply within basically a week to not close this issue... Maybe I should write my own reply bot for such occasions 😏

Anyway.

Regarding 1. "Inserting an existing native signature. This is not supported in the API." Basically, that says it. I want to access user signatures. Not have a different set of signatures for the Add-in to be used. Why? I want to create a similar experience for the workflow: A user replies to an email. By default, this will have the default signature loaded without any additional action. Now, I want to modify the text content without removing the default loaded signature. Currently, that is not possibly (AFAIK). So that creates the requirement to access user signatures if I want to modify the message text, so that I can insert the signature again afterwards. If you come up with a way how I can modify the text without removing the signature, that might be a good way.

Regarding 2. Yes, this seems to be completely #2767 and can be discussed there if wanted. First: It was supported for the COM Add-ins.

Now, sometimes there are instances where a user always wants to send HTML emails. Maybe they have a nice signature an always want to send it like that, never in plain text. Then the user actively needs to change the compose type every time they reply to plain text emails. And manually add the HTML signature after changing the compose type. An Add-in can help with this tedious task (and there are already COM Add-ins which do). I don't need to change the compose mode when a user explicitly changed it. I only need to change it when there are bad defaults that a user might not want. If you introduce an option like "always reply as HTML" that the user can select, that's also fine with me. But right now, it seems that Add-ins need to take care of it.

Also note, that Add-ins seem to be able to access and change almost always end-user explicit actions. For example, when they change the text of an email. For example, when they create calendar appointments, etc.. Basically, that's what Add-ins are made for.

[claell]

@JuaneloJuanelo