We don't use the stored and reused access token from Postman. We copy and paste the token from the process monitor to test the token, and also we run that token through jwt.ms. The token is valid. Yet, it doesn't want to be injected into our header, or somehow the header doesn't fit in the variable that should hold it (as nvarchar(max)). The database holds the data when inserted manually, so I guess the variable will hold it just the same. Stil, only that header doesn't seem to get set. Or something. Everything else works fine. The token gets retreived correctly as well. It just doesn't want to be used for the subsequent call(s).
Hi Alex, Did you check and save the cookie if any? to be reused with the other requests of the user ? We faced similar issue but was due to cookie not saved on our side to reuse with the authorization token. Hi Mperrott,We don’t get a cookie back from the Graph API as far as I can see. Should there always be a cookie?Best regards,- Alex.
Another thing I just remembered, can you double check that access_token is correct? I remember another customer having issues because the process flow variable for the access_token was not big enough causing the access_token to be cut off. Hi Dick,Thanks for the reply! We changed the domain of the variable that contains the token from VARCHAR(MAX) to NVARCHAR(MAX), to no avail.The weird thing is, that the behavior looks as if the token doesn't fit, but factually something else is going wrong. We build a header containing the token. This header we can grab from the process monitor. The token in that header can be used for calls using Postman, no problem. Also, the entire header fits in the respective column of the database that would store the call, and the results of this call. However, once we've build the header, and parse it to the next process step, the header appears to be blank, therefore resulting in a 401 response.A domain of type NVARCHAR(MAX) is the same for Thinkwise and th
This works, Mark! Thank you very much! 😀
Mark, we have a similar case as Corné's case. The difference is, though, that our first lookup is already filled up front.We're trying to filter lookup #2 based on the value of lookup #1. Lookup #1 is filled with an organization. We want lookup #2 filled with contacts from the organization as selected in lookup #1. See the screenshot below. So, “Het schaapje” is selected in the Organisatie lookup. We would like to see "contact Schaapje” as the only value in the contact person lookup, and not all contacts.We tried views and pre-filters. Yet, somehow we can't seem to grab the value of lookup #1 to use in lookup #2. What are we not seeing? The remarks about references and expression fields in Corné's topic are a bit vague to us. What is done with them, and how?Best regards,- Alex.
Thanks for the fast reply, Mark! We're not filtering per logged on user. We're filtering on selected group within an organization, and select only contacts within that organization. You've helped us realize that we're having the exact same issue as discussed here. We're gonna try to use Erwin's answer for our case.
Alright, thinking about this, I came to the conclusion that badges could very well be used for this. When the number to be shown in a badge is greater than 0, tsf_notify can be invoked. Problem solved 😊 That is the idea, at least.
Mark, wow! That was quick! 😀 Thank you! You make an interesting point. I'm looking forward to any other insights on this way of working. Thanks again, Mark!
Hi Alex, In theory it should be possible to do this with a process flow and using the OAuth connector. For example, it should be possible to set up webhooks for incoming emails and to send messages with the MS Graph API. I would like to make this so that end users can connect to their o365 mailbox themselves. I have made several attempts, but so far it has not worked. Configuring it is too complicated and there is no guarantee of success. A turn-key solution within TSF to allow end users to connect securely to the O365/MS Graph environment would be very desirable. Regards, Harm Hi Harm,Your experience is equal to ours; things are theoretically possible, but it turns out to be very cumbersome to effectively realise a solution. Thanks for sharing your findings!Best regards,- Alex. Hi Alex and Harm, We have actually already planned upgrading the Exchange connector to the Microsoft Graph API for Q3 this year. If possible, we will do this entirely using standard Thinkwise platform funct
Good to see Arie’s suggestion being turned in an "open” idea 😀 Instead of an hour based scale, we would like to take it further. Can it be a variable scale? We could use a scale of 15-minute time blocks for a client.
... Can we zoom in smaller then days (I know that question has been asked before). I haven't seen this work, but I'll ask the team if this is possible …. Hi Mark, Freddy, Our team is also very interested in the answer to this question. As we understand it, the Extender makes this possible for Schedulers using the Windows GUI, but Universal does not offer this functionality. Do we understand this correctly?Best regards,Alex
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.