PowerAutomate | EighTwOne (821)

November 22nd, 2022: Updated Flow diagram and updated blog to mention usage of vars for Mastodon host and bearer token.

And now for something completely different: With the recent news around Twitter, many people are having a look at alternatives. One of these is Mastodon, which is an open source platform, using federated identities on a distributed network. In essence, this means there is not a single phone directory but multiple, yet people living in different phone books can interact with each other as if they were residing in one (federation). Only thing is that, apart from your handle, you also need to know your (Mastodon) host where your account lives.

Now, this isn’t a blog on this social media platform, but it is a quick introduction on how to enable API access to your Mastodon account, and how you can leverage that in PowerAutomate. You can then, for example, toot your tweets (on Mastodon, one toots). There is no built-in action for Mastodon in PowerAutomate, so we need to create it leveraging Mastodon’s API, which is fairly simple for this action.

To start, you need a registered Mastodon account as well as PowerAutomate. First, we are going to configure your account in Mastodon for API access by an app. Navigate to Preferences, select </> Development and Click New Application. You now need to enter some details about your application, such as name and site where the calls originate from, e.g.

Application Name: PowerAutoMate
Application Website: https://make.powerautomate.com

The Redirect URI field can be left at its default.

At the bottom of the dialog , you need to specify which calls your application is allowed to make by means of Scopes. For this example, we will only post status updates, so we deselect anything checked, and check write:statuses, which will allow us to post status updates. Click Submit.

After submitting, return to your App details page, and you will notice at the top there is now a client key and secret assigned to the app, as well as an access token. This access token is something we need later on, so make note of it or keep the screen open.

Disclaimer: The Premium connector HTTP is used, which might require a covering Per Flow or Per User service plan. When you don’t, you will get a message during import stating that you “do not have a service plan adequate for the non-standard connection”.

In PowerAutomate, import the Flow package TootMyTweet that I published on GitHub here. During import, pick your Twitter connection to use. After importing, You need to edit the flow by choosing Edit, and make the customizations indicated below the overview diagram:

In the When a new tweet is posted trigger, change <Your Twitter Handle> in the query to your Twitter handle (or replace with any other query you desire).
In the step Initialize MastodonInstance variable, change the value to your Mastodon host, e.g. mastodon.social.
In the step Initialize AuthorizationToken variable, change the value to the Access Token you wrote down earlier from the Mastodon app configuration.
The body sets the status field to the tweet, after escaping quotes and expanding any URLs shortened by Twitter. For status (and other) API call information, see the Mastodon documentation here.
Note that replies are ignored, as context is lost when tooting replies to Tweets.

Save these changes, and do not forget to enable the Flow. Then wait for the first tweet to be automatically echoed on Mastodon.

Note that this of course is far from perfect: We will skip tooting replies (that is what the condition is for), and will do some escaping to prevent formatting issues, but shortened Twitter URLs and embedded images for example, are still shown as (short) t.co links instead of their intrinsic content or location. Improvements or suggestions are always welcomed.

Happy tooting!

On October 23rd, Microsoft announced – a little out of the blue – they were going to introduce self-service purchase options for users on November 19th. The details of this change were put forward in a post in the message center, article MC193609 to be exact. In short, this option would introduce the following changes for commercial tenants:

Allow end users to purchase Power Platform related subscriptions using their own payment method, e.g. Power Apps, Automate (formerly Flow) or PowerBI Pro.
These subscriptions could be made in their employee’s tenant, with the exception of government, non-profit and education.
It would not end with Power Platform subscriptions.
To make purchases, end users would be able to open a restricted view of the Microsoft 365 Admin Center.

While a handful individuals cheered ‘Power to the end user’, the vast majority of organizations were very unhappy with this development to say the least. This adoption booster would not only be opposing Microsoft’s own ‘Cloud on your terms’ and ‘Your tenant, your data’ principles they have been telling customers for years, it could also severely impact enterprise security and governance policies (or absence thereof), let alone lead to discussions when people expense their PowerBI Pro purchase. And I’m not even talking about the absence of admin controls.

So, swiftly after the massive backlash on social media, UserVoice as well as other channels, the announcement was altered, and a FAQ was published, which you can read here. The change itself was postponed until January 14th, 2020, and organizations would be handed controls to turn self-service purchases off before roll out.

Rather quietly, details on how to disable self-service purchase have been added to the FAQ. To read on how to accomplish this, continue reading my original blog post over at ENow by clicking here.