cancel
Showing results for 
Search instead for 
Did you mean: 

Using the Initialise page with Authenticate for Outlook 365 integration

diane.sanzone
Level 7

I am building a "pass through" object to support communication to the Microsoft 365 - Outlook object on the DX (https://digitalexchange.blueprism.com/dx/entry/3439/solution/microsoft-office-365---outlook).  My purpose is to add a few things like calculating the email box of the logged in user (in case sender/from isn't provided), validating some other required inputs, and also providing an easier mechanism to transition to an alternate email provider should my company decide to do that in the future.

I started by placing the required data items with a call to the "authenticate" action on the Initialise page of my new pass through object.  Since we're required to authenticate prior to doing anything else, it seemed a proper use of the page and also removes the need for developers to remember to authenticate -they can just call "send email" and it does it.  I've tested it a bunch of ways and it seems to work, but I'm wondering if there's something I missed?

My direct questions are:

1. Does this seem a proper use of the Initialise page?

2. Can you think of any reason why I shouldn't do this? Will it cause an issue somewhere down the line?

I appreciate any comments you can offer. These forums have helped me so much in the past; I know there's a wealth of knowledge out there and I'm hoping you're willing to share yours with me.  This is a new thing for me and we use email in literally every automation we build, so if I get this wrong it will be huge.

Thanks!

3 REPLIES 3

John__Carter
Staff
Staff

The Initialise page is intended for 'must happen before anything else' stuff, and this as you say, can be a convenience for users of the object.

One (slight) downside is that when you run the object directly in Studio, you'll have to dance around using Set Next Stage because the Initialise page won't run automatically. That, and the fact that you can't make a reference to the Initialise page. As a compromise you could make a page called Authenticate that is called from Initialise, to give the Studio user the option to make a page reference.

Another potential issue is that should the Initialise page fail, the the error will come when the process uses the object for the first time. It can be useful to have the ability to discover you have an authentication problem early, rather than mid-process. Debugging the Initialise page can be tricky too. because you don't get the option to step in. Pretty sure breakpoints aren't any use either.

Thanks, John!  I did already create a "reauthenticate" page that can be called if a page fails with an error message indicating that the user must authenticate.  My initialise page is literally just a call to the 365 action for "authenticate" and passing through the three required parameters, so there's not much to debug. I have been considering that if any action fails with an authentication error that the object automatically calls the "reauthenticate" page, then attempts to proceed. It sounds like I might not have been too far off with that thought. Do you think that might help alleviate the issues you identified?

Hi Diane yes the points I highlighted are more inconveniences than problems, and it sounds like you are on the right track. I guess the pros and cons boil down to:

Authenticating via the Initialise page: pro - the object user doesn't need to think about it; con - you could be deep into the process before you realise there is an authentication problem; con - slightly awkward in Studio.

Publishing an Authenticate page: pro - the user can put this right at the start of the process to discover a problem before starting to work cases; con - the user has to learn how to use the VBO and could misuse it.

The arguments are similar to the pros and cons of publishing an Attach page or having every other page start with an attach.