I'm using the data collection features available through Microsoft Access 2007 and Microsoft Outlook 2007 to send out an email and collect data from the recipient. The data is then stored in an Access Table.
The feature that I am using is explained here pretty well: Collecting Data Using Email
The issue that I have run into is that other than the email address, there's no way to customize the email that is being distributed. What I'm hoping to accomplish is the ability to essentially do a mail merge of sorts to personalize the email. This doesn't seem possible using the wizard approached described in the attached article. Is this something that I could accomplish via Visual Basic or some other means within MS Office.
If you've chosen the HTML-option you will get only text boxes and there is no way to customise the email if sent directly from Access. If you do not specify an email address, Access will generate the email so that you can type in the recipient - you can customise the email at that point.
If you do want all the fancy stuff (ie, customising the email, using drop downs, yes/no buttons, validation etc) then you'll need to use InfoPath as a source (again, if using Access). That's the application where you can build your form using validation and controls. The disadvantage is that the recipient needs to have InfoPath installed on their machine.
You could of course create an application to loop through your records and you can customise the HTML as much as you like then, this is probably best done outside of Office.
Related
I have a VBA function in our MS Access database that generates Outlook emails and sends them from a shared inbox.
Our company uses Azure Information Protection to protect documents. A label needs to be applied to each email before it is sent (e.g. Public, Business Sensitive, Internal).
Rather than having the user click the label 25 times as it pops up for each email, I am trying to apply it programmatically.
I get error code (-1248837627).
My solution was to grab the labels GUID and then apply it to the email as below. I came across other solutions such as using SendKeys but I prefer it to be a last resort.
With olMail
.To = olSendTo
.Subject = olSubject
.PermissionTemplateGuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX"
.Permission = olPermissionTemplate
'And so on, the email function works great until the above two lines are added
Am I applying the .Permissions or .PermissionTemplateGUID improperly?
I have seen a similar approach to apply labels to Excel documents (grabbing and setting the guid).
The code you posted is used to specify Information Rights Management (IRM) permissions. Azure Information Protection is another story.
You need to add a user property in the following format:
"MSIP_Label_" & guid_internal_use_only & "_Enabled"
But I'd suggest exploring internals of Outlook mail items using MFCMAPI or OutlookSpy to find the exact solution. Try to set it manually then explore internals using these tools.
I need to have an office add-in component (https://dev.office.com/getting-started/addins ) to allow user to select a contact from the global address book to insert that contact email in the word document.
Any suggestions if this can be done with office add-ins? if yes how can it be done? or it must be VSTO?
An Office Add-in is simply a web app (that happens to run in the context of an Office host), so you can design it to do the types of things that a web app can do, including issuing requests against REST APIs. Regarding the scenario you've described, I'd view it as 3 distinct tasks:
Get contact info from AD.
Present list of contacts to user (so they can select one).
Insert email address of selected contact into document.
1- Getting contact info:
Re the specific scenario that you've described, I'd suggest that you investigate the feasibility of using either the Microsoft Graph API or the Azure Active Directory Graph API to get contact information from the GAL. Please note that, in general, using Microsoft Graph is recommended over using Azure AD Graph.
2- Presenting list of contacts to the User:
Regarding UI design, because your Office Add-in is simply a web app, you can present the list of contacts to the user in whatever manner that your web app supports.
3- Inserting text into the Word document:
Regarding inserting text into the document when the user selects a contact via the Add-in UI, you'll use the Word JavaScript API to do this. If you haven't used the Word JavaScript API before, I'd suggest that you start by doing the Word Add-in quickstart, which shows how to insert text at various points in a document. Then, for additional details about the API, see the Word JavaScript API reference docs. (Which API operation you use to insert text into the document will depend the specifics of your implementation. I'd suggest that you post a separate Stack Overflow question that describes specifically what you want to achieve re insertion of text into the document, if you need help with that when the time comes.)
I am writing an Outlook addin that inserts content into an email, and I have a emailSent event that I would like send an event back to my server letting me know some content was shared.
Is there a way to attach some meta information to the email (or the word doc, which is what you are creating in outlook) so that I can grab that meta info so I can send it back to my server.
Right now, the only way I think I can do it is to search through the email on the send event looking for my content with regex and pull out the info i need, but that seems cumbersome, and also means I need to run the regex for every email sent, even when they haven't added my content.
There is the concept of MAPI user properties, which you can add to an Outlook item. Since Office 2007 the object model allows access to them. If your add-in must run also with older Outlook version, you should recurr to use Redemption (which I prefer also for higher office versions because it has more flexibility, albeit a greater footprint in distribution).
See UserProperties Interface on MSDN.
I'm interested in automating some reactive work I do when receiving certain emails in one of my email accounts. What I would like to have happen is:
On receipt of new email in the account
If the new email passes the "Need to React" criteria (based on body content and subject line)
3a. Scrape some content out of the email body and subject lines
3b. Populate a template form (e.g. Excel spreadsheet) with the scraped data
3c. Print the populated form and save the populated form in some folder (e.g. as a pdf)
What's the best (defined as easiest to implement by myself) approach / combination of technologies for achieving this automation?
i have not done exactly what you are asking, but I know Microsoft Outlook has a Rules engine that can take incoming messages, check for various content, and then do various actions including running applications and/or scripts.
You should look at Visual Studio Tools for Office if you are a c# person.
http://msdn.microsoft.com/en-us/vsto/default
You can write an Outlook add-on that can do pretty much everything you have outlined above.
I was just introduced to the concept of Outlook forms. I don't know if this will solve my problem but here is what I want to do:
I want to be able to have employees who are inside the company fill out some forms. So all I have to do is create the form and PUSH it to their Outlook? After they fill out the form, can I capture the data somehow? Has anyone does this before? Can someone recommend a good tutorial/examples?
Update: The Outlook->Access option seems like a great one, but it seems like the form must be emailed by someone. In other words, if someone wants to fill out any form they first have to be emailed a form. What if a person wants to just fill out a form? How would he do it if he has no access to the Access database?
Here are three options:
This page is a really good jump page for custom forms in Outlook. In fact, that whole site is pretty good with lots of examples and links like Outlook Forms Step-by-Step Tutorial.
However, if you also have Access 2007, I'd actually recommend something simpler and easier to create email forms that can be sent to users and collect back all of the information. Once I discovered this in Access 2007 I never went back to custom Outlook forms.
Basically, you create an Access db with the data you want to collect and then in the "External Data" tab in Access 2007, you click "Create E-mail" and a wizard will walk you through creating an email with the form in the body (which is either HTML or InfoPath, depending on which one you choose). You send this to your users (you can have a recipient list in a table as well in your Access DB) and they fill out the form (I used it for surveys) and then they click submit. It goes back to your Outlook in a special folder and as soon as you open Outlook, it will synch it with the database. Then you can slice and dice all of that database information.
Here are some great tutorials on this:
Demo: Collect data in Access 2007 by
using e-mail
How to integrate Microsoft Access
and Outlook 2007
Finally, if you just want to collect back much simpler information, like "Yes", "No", "Maybe", the easiest way is to create voting buttons. Go to New Message -> Options - Voting Buttons. You can customize this if needed by separating your choices with a semi-colon ;.
In #2 and #3 above, these are scenarios to initiate data collection.
There are other situations where someone doesn't need a prompt via email to fill something out right there, but rather just submit a form (like an expense report, or a gas mileage report). #1 above (Outlook custom forms) is generally better choice in that scenario, but:
Outlook forms have typically been
harder to deploy and teach people to
use (there are things like "public
forms", "private forms", etc.)
Outlook forms have been, in practice,
been replaced by other technologies.
In particular, InfoPath/Forms Server and
Sharepoint Forms. This is because neither
of those two technologies requires
users to do a whole lot other than
follow a link to fill out a form. I used to know, about 10 years ago, many companies who tried to use Outlook forms and most of them gave up development of them in favor of other technologies.
This isn't to say that Outlook forms are bad in any way. If you don't have other technologies available to serve as a Forms Server, then this could be a decent option to consider.
To look at other semi-lightweight ways of form submission, you can use MS Word templates as the front end and have them update an Access DB. Here are a couple of good articles on this:
Import Data Directly from Word
Forms to Access Tables
How do I... Transfer data from a
Word form to an Access database?