I am trying to create a 2-stage approval in Microsoft Flow, a fairly trivial task in SharePoint Designer.
I added a SharePoint trigger : "When file is created or modified (properties only)" and configured it for my site and document library
Then I added a "Start an approval" task and configured it to send the approval to a user
When I tried to test the workflow, it fails on the first step, with the following error message:
Status code: 400
{
"status": 400,
"message": "The required field \"Funding Type\" data type is not supported\r\nclientRequestId: 22a926d7-1b8b-4a97-bffe-cd6deca42327",
"source": "https://<website>/Policies-And-Procedures/_api/SP.APIHubConnector.GetUpdatedListItems",
"errors": [
"-1",
"Microsoft.SharePoint.SPConnectorException"
]
}
The FundingType field it fails on, is a Site Column linked to a Termset and is set as Multivalue.
It's a bit disappointing to have it fail on such a trivial scenario.
Hoping, I am missing something small.
According to this (https://powerusers.microsoft.com/t5/PowerApps-Forum/data-type-is-not-supported/td-p/24248), site columns with multiple values are not supported.
I changed my column to accept only a single value and that fixed it.
Related
We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
When developing a message extension for Microsoft Teams, is it possible to retrieve the ID of a team where the user is invoking the message extension command without first adding the bot to that team?
I can do this when the bot is added to the team manually based on TeamsInfo.getTeamDetails(), however, I don't really need (or want) to add the bot to the team for my goal. All I need is the channel ID (which is available from the context/conversation) and the ID of the underlying team. Retrieving the team details without the bot being added beforehand errors with "The bot is not part of the conversation roster".
Have a look at the ChannelData property on the Activity class, that should give what you need. You can read more about it here.
Here's an example of the underlying payload, for interest:
"channelData": { "eventType": "channelCreated", "tenant": { "id": "72f988bf-86f1-41af-91ab-2d7cd011db47" }, "channel": { "id": "19:693ecdb923ac4458a5c23661b505fc84#thread.skype", "name": "My New Channel" }, "team": { "id": "19:693ecdb923ac4458a5c23661b505fc84#thread.skype" } }
we had the same trouble with the Team documentation and APIs.
However for that specific case, we found a solution that may work for you. I will say is more a hack than a solution. But it worked on my use case. It will only work on messages with attachments.
When the context is received in a message, the message contains an attachments array. Each attachment object has a contentUrl. Inside that url is the mailNickname for the group. That mailNickname field represents a readeable unique id. The format is something like sites/{mailNickname}/General.
from there you can retrieve the field and use the Groups Graph API.
With a query like this one:
https://graph.microsoft.com/v1.0/groups?$filter=startswith(mailNickname, 'themailNicknameFromcontenturl')
You will get the group full information, including the aadGroupId
In general, is a nightmare to work with Teams documentation. Hope this hack helps you.
I am using an access token with ZohoCRM.modules.custom.READ.
When I send a GET request to https://www.zohoapis.com/crm/v2/Custom/search, I get the following error.
{
"code": "INVALID_MODULE",
"details": {},
"message": "the module name given seems to be invalid",
"status": "error"
}
What am I doing wrong and how do I define the module I am trying to pull data from (it is called CustomModule2)?
Figured it out...
First, needed to go to https://crm.zoho.com/crm/{org_id}/settings/modules to find the actual name of CustomModule2 which is Adresses livraison.
Then, needed to go to https://crm.zoho.com/crm/{org_id}/settings/api/modules to find the API name for Adresses livraison which is Adresses_livraison.
Finally, needed to go to https://crm.zoho.com/crm/{org_id}/settings/api/modules/CustomModule2?step=FieldsList to find the API name of the field I wanted to use as a search criteria (it was Compte].
The final query using httpie is as follows.
http GET https://www.zohoapis.com/crm/v2/Adresses_livraison/search \
Authorization:"Zoho-oauthtoken {access_token}" \
criteria=="(Compte:equals:{account_id})"
Zoho is up there in the most awkward developer experiences I have encountered.
Just an update for anyone still looking into this, because I noticed that the links aren't always the same, depending on whether it's a sandbox or not, etc. So the steps are:
Go to your CRM page/dashboard and click on the Settings (cogwheel icon) on the top-right, next to your account image.
A bunch of items in panel boxes open. In the panel named "Developer Space" choose APIs
There it opens a bunch of tabs and sub-tabs and a Dashboard (As shown on the image below). The "Dashboard" sub-tab should be selected, all you have to do is switch to the sub-tab "API-Names"
So I need to essentially create a PowerApp which would make appointments in Dynamics CRM. All data gets sent to CRM - except the case regarding the appointment.
Originally, I was using the normal SubmitForm() but switched over to the Patch() function. I have set the _regardingobjectid_value to a valid case GUID. The problem lies with _regardingobjectid_type - as for some reason, I cannot set the entity name. In this case, the entity name would be "incident", but it keeps throwing an error that states that it needs another GUID. I really don't know what to do anymore.
This is the code I am using:
Patch(
Appointments;
Defaults(Appointments);
{
Subject: txtSubject.Text;
'Start Time': DateTimeValue(_selectedStartTime);
'End Time': DateTimeValue(_selectedEndTime);
Description:txtDescription.Text;
_regardingobjectid_value: _regarding;
_regardingobjectid_type: incident
}
)
So to clarify, I would just really like to have my appointment have the specified case regarded to it.
At the moment I am getting an error stating that incident "name is invalid". If I remove the type, I get an ambigious error. And when I set the case id to the type, it does input my record into Dynamics, however with no case (understandably so).
This should work. Exact same problem is solved in this blog post.
You have to make sure to set this Use GUID data types instead of strings setting in App settings.
Patch(
Appointments;
Defaults(Appointments);
{
Subject: txtSubject.Text;
'Start Time': DateTimeValue(_selectedStartTime);
'End Time': DateTimeValue(_selectedEndTime);
Description:txtDescription.Text;
_regardingobjectid_value: GUID(_regarding);
_regardingobjectid_type: “incidents”
}
)
Edit:
Nick mentioned in his blog about this. Should be a known bug.
The only reason why I choose Flow as opposed to writing directly to
CDS from the PowerApp is that at this point you cannot set the
“regarding” when you write to a task in the Canvas based PowerApp, but
you can using Flow.
As our team ( namely myself and two other developers ) spiked on PACT past week or so, one of the areas of concern is not having the ability associate parameters to provider states. The absence of this key feature ( which is slated for version 3 release ), we likely will not get buy in from each of our respective service sub-teams.
#MattFellows - Any projections on when version 3 might be available for Go? Any chance we can get this feature earlier?
Allow multiple provider states with parameters
In previous versions, provider states are defined as a descriptive string. There is no way to infer the data required for the state without encoding the values into the description.
{
"providerState": "an alligator with the given name Mary exists and the user Fred is logged in"
}
The change would be:
{
"providerStates": [
{
"name": "an alligator with the given name exists",
"params": {"name" : "Mary"}
}, {
"name": "the user is logged in",
"params" : { "username" : "Fred"}
}
]
}
You are correct in that it won't be available until version 3.
You can still achieve what you are after, however. The state itself is just a handle for the Consumer to some set of data on the Provider - that can be a one-to-one or one-to-many mapping - it's completely up to you.
Typically the Provider is notified of the state during verification, it will then setup a test data fixture (often seeding a database) that sets up the 'state' of the entire system based on that reference, which allows the Consumer test to run.
Whilst the ability to pass through parameters and multiple states is nice, it's somewhat an advanced feature and I very much doubt this will be the first problem you run into as a team. I've never needed to use them myself.
For a crude but effective example of this, take a look at the gin code in the examples folder of the project.