I would like to create a new email collector each time I identify a new group of respondents, create recipients and track responses for that new group or even one individual.
I have a 6 surveys that I reuse over and over again. I currently use a web link collector with custom variables and capture the email address in the survey to identify responses. I currently use a webhook and the api to download responses.
This approach is problematic for several reasons:
I cannot define the groups up front before I administer the survey
I want to be able to use the collector again at a later date to administer the same survey to the same group
email addresses are mistyped and cannot be verified to track responses over time.
This was the response I got from the Sr. Technical Support Engineer.
While there's no defined limit, performance implications (in terms of
accessing Analyze Results) are something that a large number (w/ large
numbers of responses) could encounter.
Related
I'm designing a web application that needs to retrieve and organize emails from at least 100 mailboxes from our company's domain. Something like:
abc#company.com
cde#company.com
efg#compnay.com
...
My web app needs to check each of these emails every couple of seconds to retrieve the new emails and index them. However, I don't want to hit the API limit for them.
Reading the official documentation, it seems like I can have a single app ID and use it to retrieve all these informations and won't hit the API limit.
If I have 100 mail boxes, and let's say, check each mailbox every 10 seconds (with maximum 4 concurrent threads), is it safe to say that I won't hit any kind of rate limit?
It might be worth mentioning that I'm going to use the Delta Link feature to check for new emails. This will make things faster and I'm not sure if it has any effect on the rate limits.
You really need to decrease the frequency of direct hits and only do that once you receive a notification from a particular mailbox/folder.
See https://learn.microsoft.com/en-us/graph/api/subscription-post-subscriptions?view=graph-rest-1.0&tabs=http for details on Graph event subscription.
I work in a large enterprise where multiple teams are developing Lex bots (on separate accounts). Each bot supports a different domain or application,. In some cases, it would be nice for a single user interface to ask a question without needing to know which bot to ask. Is there a way to federate bots, or to forward un-recognized intentions to 'backup' bots?
I feel like what I really want to do is treat each bot as a skill is treated in Alexa, except I'm in the position (through entitlements) to know which 'skills' would be appropriate for a given user.
The answer here is that you would need to develop a custom application that delivers a user's input to each of your company's array of bots.
You'd need to look at the NLU Confidence score from each Bot's response to decide which response is the most accurate to return to the user. Would also be worthwhile keeping some state in your app to remember which Bot the user is currently interacting with and defaulting to that Bot for successive user inputs. Should you reach a point where the confidence score is low, it might present a signal to you to test the user's input across the other Bots.
What you'll need to be aware of here is that your costs will increase with each additional Bot that you add. So, assuming you have 5 area-specific Bots, one inbound message from your user could result in 5 Lex calls. As you start moving into significant volumes of interactions, this could start proving to be an obstacle.
An alternative would be to use a custom fallback intent to invoke a Lambda function that calls your Bot orchestration function. Assuming that you're able to find the correct Bot to handle the user's query, you'd need to remember that so succesive messages now get routed to that Bot.
On a ride booking app, it is required communication between driver and user.
Now the case, if user A contacts the driver via website or app, call or sms can be achieved via Twilio, we don't want to expose their contact numbers to each other.
If three users A, B and C contacts the driver and driver has no app installed, in fact the driver wants call back and sms reply. How the driver can reach users on Caller ID.
There could be large number of users and we can't buy separate twilio number for each user.
Please advise the solution.
How many users are likely to need to contact each individual driver at any one time? Not many I wouldn't think.
Buy 10 Twilio numbers, assign them incrementally as users call/SMS their driver and save the assignment for user/driver numbers in your database.
If the driver calls/SMS a number in response query the database and route the call/SMS to the user it was assigned to when they called the driver.
Recycle the 1st assignment once the 11th user calls/SMS the driver, rinse and repeat.
Twilio developer evangelist here.
In order to maintain anonymous communications in this way you need as many numbers as the maximum number of relationships one person in your system has. The best explanation of this is in this article on masked text messaging with Twilio (though it applies to calls too).
Your comment on miknik's answer suggests you want to keep these relationships alive forever. This is not the way that most services build out this feature. They normally give a particular length to the relationship, Uber for example will recycle the phone number a number of minutes after a ride ends.
If you are looking for an easier way to manage this kind of number pooling and masking, check out Twilio Proxy, it handles a lot of the logic for you. It is still in developer preview right now, but you can apply for early access.
I'm working on a D2L add-on right now and trying to retrieve all the courses the current user is enrolled in. The only way I found so far is using the
GET /d2l/api/lp/(version)/enrollments/myenrollments/ call. This works perfectly for a small amount of courses and is extremely slow for more than approximately 50 courses. Is there any better way to retrieve all the enrollments?
Thanks in advance
For end-users, this call is indeed the one intended to address this need. Since a portion of the performance drop may come from having to process a series of data pages (requiring several calls), you can try several techniques to add a bit of performance here:
You can pre-filter the call based on org unit type: this likely requires you as the app developer to know the org unit type IDs for the org units of interest to your end users. For example, if your main use case here is "student wants to see all the course offerings she's enrolled in", then you can provide the appropriate org unit type ID for course offering org units to your API call. This becomes more difficult if your app must address several different back-end services, or you don't know the org unit type ID used by the back-end service for the relevant org unit types.
You can try using an HTTP library that can pool connections, and batch together the calls that fetch all the data pages you need to get the complete list of enrollments needed. This will provide you with some benefit to overhead on each call, but the performance benefit will likely only be marginal.
Currently, this API route does not allow the caller to request a particular data page size, and allowing that would improve the overall latency involved in this use case: for example, requesting a page size of 500 records could conceivably fetch back all the enrollments in a single call. I would judge page-size requesting to be a completely reasonable feature enhancement to request, and I would encourage you to request it on D2L's Product Idea Exchange; in fact, I'd be rather surprised if someone hasn't already done so.
I'm creating a twilio service with three actors:
The customer, a person who calls a company
The company, a company who forwards calls to the service-provider
The service-provider (that's us), an entity that services the customer on behalf of the company
Herein lies the catch: The service provider needs to be able to identify the company associated with the customer but it may only use a single phone number. We cannot use multiple phone numbers for cost reasons (the margins are that low). We cannot use the caller id because a single customer may be associated with multiple companies.
I am familiar with Twilio's ForwardedFrom field but as mentioned here it isn't always reliable. In fact, forwarding from my cell-phone carrier results in a null ForwardedFrom field.
How can we (reliably) identify the company who redirected a customer to us without using multiple phone numbers?
You can use the number + extension. http://www.twilio.com/docs/howto/ivrs-extensions
Perhaps you could build a sort of phone tree system, asking the caller the nature of their problem, which would be an indicator of the company their call is related to.
My guess is that you wouldn't want an outright "which company are is your call related to?" question, because that would feel cheap to the customer. So, maybe you could formulate a question or series of questions that wouldn't be overtly asking which company their calling about, but the answer(s) would clearly indicate on the service-provider end which company the call is about.
This could be further whittled down on the service-provider end by doing a company lookup based on the customer's calling number - if it matches a certain company (or set of companies), then that automatically limits the potential company they could be calling about.
Another possibility (if it fits in your use case) is some sort of we'll-call-you setup. Perhaps the customer could text/email requesting a call, and the information they'd provide in the text/email/online-form-submission would indicate the company they wish to speak about (again, you could use questions that aren't overtly "which company do you want a call from?").
Then again, if it's such a low-margin operation, maybe the companies are ok with a phone-tree style call-in number, where the customer needs to select a company they're calling about which is then indicated to the service-provider.
This doesn't seem to be possible at this time (2013). I will keep an eye out for new answers and will accept them if this becomes possible at a later time.
In general, I'd recommend separate numbers per customer but since you say that's not an option, here's another approach:
When the call comes into the Company, that individual leg gets a CallSid which is a unique identifier. When the call is forwarded to the Service Provider, that separate leg also gets a CallSid. Let's call them CallSidOne and CallSidTwo respectively.
If you then query based on CallSidTwo, you'll get back its instance properties as listed here:
http://www.twilio.com/docs/api/rest/call#instance-properties
The key property here is "parent_call_sid" which should be CallSidOne. Therefore, you can connect the two segments together.. then you can query on CallSidOne which gives you the ability to track who called which customer called which customer when.
Does that solve your problem?
~Twilio employee