How do you send a [survey-link] that creates/links to a new instance of a repeating-instrument survey in REDCap?
ie imaging you have customers who should visit you on a regular basis. You have two instruments:
customer
visit [set as a Repeating Instrument + enabled as a Survey]
And you have an alert that regularly sends them a "Time for your next visit" email.
When I send an alert to a customer with [survey-link:visit] it will work the first time. The email will contain a unique URL for that customer's visit. But when the alert is sent a second time, person will open the URL and get a "Thank you for your interest, but you have already completed this survey."
I can manually (via the web admin) create a new instance of their Visit. But how should I do this automatically?
Thank you.
As of version 12.5 this is now supported using a smart variable [new-instance] which, when appended to a [survey-url] or [survey-link] smart variable, will target a new instance of the instrument if it is repeating. In the same release came ASI options around repeating instruments, which allow you to repeat an ASI every X minutes, hours or days, and each successive ASI instance points to the specific instance of the survey instrument. This is useful for daily surveys.
For your use case, [survey-link:visit][new-instance] will do what you want. Send it to them once and instruct them to fill it out as many times as needed, or send it however many times you need to.
====
Yes, this is a current limitation. It has been requested of the REDCap developers to add a smart variable [new-instance] that can be appended to a [survey-link] or other smart variable to instantiate a new instance of a repeating instrument, and they have responded positively.
Maybe the most appropriate workflow here would be for you or the project staff to manually create the visit instance, save it with a date, and have an alert that sends them an invitation to complete the visit details, or whatever you need them to do.
If you want the respondents to instantiate the visit themselves (i.e., make a booking rather than respond to a booking made on their behalf), the only workaround I have personally managed is to enable the survey queue and activate the repeating instrument on the basis of some logic (say, [consent] = 1), and in the survey settings of the repeating instrument, enable the option to Allow respondents to repeat the survey.
With these settings, the survey queue will allow the survey respondent to create a new instance of the instrument themselves by clicking the 'Take this survey again' button (button text configurable in survey settings). They can be emailed their link to the survey queue via an alert using the smart variable [survey-queue-link] or [survey-queue-url].
For extra credit, you could get fancy with the survey queue logic so that the instrument is disabled if, say, the last instance of the survey has today's date, using something like [consent] = 1 and datediff([visit_date][last-instance],"today","d",true) > 0. With this you could prevent them smashing it and adding multiple new visits at once.
Related
Love the order ahead use-case: https://developer.squareup.com/docs/orders-api/order-ahead-usecase
Trying to figure out though. It says: "The customer kicks off the process by ordering one small coffee and one chocolate chip cookie using your order-ahead app. The customer chooses to pay using the app and pick their order up at CoffeeCool’s location."
Can the customer therefore "choose" to pay at pick-up? I'd still want the created order to be sent to the POS, so that the kitchen can start preparing it and the customer is not waiting.
Essentially this would be like replicating the "Save" rather than "Charge" option if this order were being manually made at the Square POS.
Currently only orders that have a charge associated to it will appear in the Square app and unfortunately the option to pay at time of pickup isn't currently available.
Yes You Can. You can set it up from the dashboard ( your computer) not directly from the POS. The issue is that it will prompt you to give a name to the order
Giving I have a dialog tree for booking a rental car.
The bot have a main Intent called "orderIntent" and a second intent called "colorIntent".
In the "orderIntent" dialog the user will be asked to chose for a car category, date, and price (all of those have a separate slot in this intent).
I want that the at any given moment in the dialog the user will be able to call the "colorIntent" intent and set up a color as he desires and when this is finish, to return back to the same place in the tree dialog that he previously left.
For example, when the user will be asked to pick a date for the booking, and will reply with "I want to chose a green color for the car" this will invoke the "colorIntent" intent and the user will be able to chose a color.
Afterwards the user should return to the same part of the dialog that he partially fulfilled and will be asked again to pick the date of the booking. I want to achieve that while maintaining the information he already partially fulfilled in the main dialog about the car catagory and price he already picked and the new information about the color he picked from the "colorIntent" intent.
How can I configure such logic in the AWS Lambda of the bot ?
https://github.com/awslabs/serverless-application-model/blob/master/examples/apps/lex-book-trip-python/lambda_function.py
Try seeing book_car function this will solve your problem. Because here they are taking some slot values of book_hotel and setting up in book_car.
Make use of sessionAttributes to achieve this because sessionAttributes remain across intents, while slots are only held within each intent.
Intent_A logic can run, filling slots as it goes, and the slot values should also be saved in sessionAttributes. Then at any point of IntentA, a user could trigger Intent_B.
Now Intent_A's slots are overwritten by Intent_B's slots but Intent_A's slot values are still saved in sessionAttributes.
Extra Information on how to change between intents:
You then have 2 choices:
(1) force the user to trigger IntentA again
with a prompt like, "To continue booking the car, please say, book a
car".
(2) use confirmIntent back to IntentA, but it will need to
ask a confirmation question like, "Would you like to continue booking
a car?" The response to that will go to Intent_A regardless, so
inside of Intent_A you need to just check the confirmationStatus
which will be either "Confirmed" or "Denied", based on how the
user responded to that question. If confirmed, then you can continue
Intent_A, and if denied, then you should close Intent_A.
(look into confirmIntent here under types of dialogAction)
After getting back into Intent_A, you should then check if any slot data is inside of sessionAttributes, and force this data back into the appropriate slots. Then your original logic can detect which slots are already filled, and continue where it left off.
Ho everyone, I'm in trouble with my campaign, this happened to me... when i go to my list to see the data of the recipients.
It is asking me to create a reconfirmation Campaign, due to a too high volume of unsubscribed to this campaign.
Here the path I've been following to realise my campaign ( It is the first time I'm using Mailchimp):
I have an invitation to a event where guest can approve or decline the invitation.
When they Accept the invitation: it bring to the update profile form - which icahnge in the advence editor. This way We can record some data such as dietary requirements,etc which would be recorder to our subscriber list ons submit.
When people decline the invitation, we have link to the unsubscribe form. This way we are able to know Which person has decline the invitation.
From what I understand, this is way It stopped our campaign.
What I'm looking to achieve . . . and din't manage i slept 2 hours last night trying to make this work . .. and i m in a big rush :
How can I achieve to collect data with the path explain previously, without having this issue in the future - so without using the unsubscribe from - but two different forms ?
How can I access to the List of User who have accept the invitation, so I mean the Subscriber List. because since that happen, I can't access it - and obviously i don't want to send another email to the guests asking them to fill up again.
I really appreciate all the help that anybody can provide me with that,
Thank you guys !
If I'm understanding you correctly, you're trying to use list subscriptions to stand-in for RSVPs? That is likely to look really bad -- ESPs see high volumes of unsubscribes as suspiciously spammy -- you'd be better off using Interests or Merge Fields on your list to denote the user's RSVP rather than asking them to unsubscribe. As for your current account, follow the instructions in the email you received if you want to get your list back up and running again.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have a website where I've done a "mission generator" to encourage engagement. I've hard coded 3 sets of missions (Easy, Med, Hard).
Easy missions have 6-8 cases that could randomly happen
Update N times your hero (N is random number)
Update specific skill
Rest your hero for a day
etc..
Med and Hard require 1 task which is harder to achieve and adds two from the Easy tasks.
My generator works great but I would like to know how to design the reward system so that it is hard to game by the users.
The problems that I have are sort of:
The user might decide to quickly achieve the tasks and then delete them as soon as they get the "achieved badge"
For example
Update 3 times your hero
Add a new skill
Send a message to another hero
What I see as a problem is that the person might decide to update 3 times, choose a new skill and send a message, then erase the 3 updates (there is such a feature) remove the skill and delete the message that he has send.
So far I've come up with the following ideas but I'm looking for an opinion from someone who has done something like that.
- First approach:
Hard-code a table in the database with columns for each possible combination say
row1 - Updates | row2 - New skills etc...
Downside: I'm afraid that the row could end up very long and it would be hard to manage and add new types of challenges. The whole concept become very rigid.
- Second Approach:
For every task assign a unique id and once a skill or update or whatever is added append that to the task number.
Downside: every member gets 3 daily missions (which could be extended in time) if the generator requires on average 3 updates per mission that makes it to roughly 10 updates per user per day, adding to that the actual records for the updates with the data it adds up pretty quickly for a couple of thousand users. I would say 90% of this data will be useless and will just generate bills.
- Third approach:
Add a column to the table with the updates, skills (and all the other tables which are used in the missions). Then, when the user adds a new skill (for instance) the challenge ID will be added to the column in the skills table, then if the skill is removed the mission will fall back to "unachieved" (same goes for the updates and the other skills)
Downside: This might turn out very messy when the challenge is "put hero to rest for 1 day" because if the generator asks that twice between two days, the user will lose the first achievement of that sort because the challenge ID will be overwritten.
A big question is - what happens when the user decides to cut corners and delete some of their skills. I presume their missions will start piling up? (kind of like a punishment)
Try making some things more dynamic.
For example: You could put the skills in a static checkbox list on the side, and select or deselect them. Then add a button to delete the selected skill, and skills are added to the static checkbox list by selecting a skill on the page itself, outside of the checkbox list.
The skill is then added to the checkbox list as an element.
When you need to rest your character for a day, it's pretty much impossible to do that twice in one day. Make it so that the rest for a day event can only happen once in a day.
This way there is no need to worry about overwriting, and the player doesn't get confused as to why his hero needs to rest twice. Perhaps make the resting bound to a stamina bar that decreases with certain events. When you add a skill perhaps the training can cost stamina. When the stamina runs out his hero needs to rest.
About removing updates and skills:
It is not a very good idea to make things removable right after being added.
Make it so that the skills and updates can only be removed after a certain time.
Long enough to confirm the achievement and store the achievement.
Then they are able to remove their skill and updates and the achievement which was already saved won't disappear.
Sending a message to the other hero:
I have a question about that.
Why would you be able to remove the message.
Is the message sent to another player?
If so, it would make no sense to be able to remove it.
Also, sending a message obviously happens server side since it goes to another player so you can set it to done server side.
I have a requirement to be able to accept different forms of payment within the same order - ie not just the usual credit card or paypal for the whole thing, but perhaps paypal for one item, cheque for another. I know this sounds quite crazy, but there is a good business reason for the requirement so I can't just push back.
The best way I can think of implementing it at the moment is to have kind of a hub page, where you can "launch off" into multiple flows for each of the payments by opening new windows. I can't figure out a way of doing this in a linear flow as for example you can't guarantee that a user will come back from paypal, so you'd then lose the user completely.
Is there a neater way of doing this that anyone can think of, or can anyone point me to an example of a site that does somethign similar for inspiration?
Even when opening several windows at once, there is no guarantee that the user will complete all payment methods. So you are most probably going to lose a few users or payments. Be sure to send automated e-mail follow-ups for missing payments to minimize this problem. The e-mails could contain links to your payment providers for easy accesss to their outstanding payment operations.
This is a difficult problem, but how many payment processors do you have to go offsite for? Should only be paypal.
In any case, I'd give the user all their payment options on one page, and let them fill in the amount for each processor or payment type. Then the next page would list those they chose, the amount for each, and a link to "Complete this payment".
The link would open in a new window.
You'll have to have a good back end and javascript, as well as user warnings so that the payment page gets updated as each payment is processed. Consider using popup dialogs to show that a payment has completed, or that the order has sat idle for more than 10-30 minutes without complete payment.
Also, consider sending emails and letting the user complete the payments through links in the emails. Send a new email each time a payment is completed, and a final email if all payments are complete and the order is moving forward.
Send an email one hour, and one day later for uncompleted orders with remaining payments required, that also give them the option of choosing different payment options for the remainder.
Email isn't best (lose more orders that way due to changing minds) but it's good for the type of transactions you're thinking about.
Personally, I'd do it like this:
Let the user fill their basket in the ususal way
Allow them to add payment types and amounts to a list (2nd basket almost)
When the payments balance against the basket, start processing the payments
For external sites, try a frame which has a progress indicator at the top.
In an ideal world it wouldn't be linear. But a lot of users might lose a spawned window, or get confused by the parallelism.
Better to stick to established IxD principals and rely on good feedback instead. Give the user control from the outset and keep it transparent.
Lastly, start the payment process with the most immediate (e.g. paypal) to reduce users giving up. (COD should come last!)
Hope this helps,
Tom
If possible, just separate your order into separate smaller orders based off of the payment selections of the user.
And don't do it linearly. If anything you could open up each payment processor in a separate window so that you maintain presence.
I would take an approach where the whole order is broken down into sub-orders for each of the necessary payment methods. You can load the PayPal portion, the check portion, etc. and process them separately. It's important for the user to know how much is being charged to each of their payment methods, so it makes sense in this case to present the whole order as broken down by payment method (versus displaying as a unified order).
Implementation would be easiest if it's always a certain subset of items that is forced to any payment method. If this differs by user, or if it's when the order reaches a certain amount, the situation could become much more complicated. Can you be more specific about your approach?
Processing Multiple Order Payments
Give the user the option to make a payment for a pending order using any of your payment types.
Let the user specify an (Amount <= [Order Total] - [Payments Received]), if that is part of your requirement.
If the order is still pending after you process the payment (see how below), take them back to step 1 to rinse and repeat.
How to store and process each payment made:
Use a Payments table to store all order payments, the PaymentMethod used and its Amount with its CurrencyCode.
When a payment is received for an order, store the payment and sum all received amounts converted into your base currency as [Payments Received].
If [Payments Received] >= [Order Total], mark the order as Paid. Or, if dealing with double-converted foreign exchange rates, check if it is correct to within a small-enough margin, eg 0.5%.
Optionally, convert any overpayment into prepaid credit for the client.