Note: this help page is phrased with respect to the List view (i.e. 1 activity/row), except where noted.
Clicking on a Request This or an Apply for This creates a signup request. All other button labels result in the signup being completed immediately (see self-signup help for more on this).
As you enter a name to signup, matching registered people are shown (even if what you started to type was an email address). But if you are not sure you have identified the intended person, doing Search People Database might help. Conversely if the No Matches message is displayed, you can do the Register right then and there by clicking on its here link.
Unless an activity's type is Reservation, you may over-assign people to an activity/time, such as when someone "walks in" during the event and offers to help out. (Alternately, you could increase the number of spots a schedule item has by clicking on its time).
Note: In the grid and calendar layouts, the command labels are shorter. For example, "Signup for This" shrinks to "Signup".
If your schedule view shows signups or you click a zoom checkbox, you can examine or edit a person's signup.
Note: In the grid and calendar layouts, the links have been merged into the status menu. For example, the EMAIL icon becomes the SEND EMAIL menu item. Also the person's name is always the current item of the menu, and you bring up the person's registration form by selecting the REGISTRATION INFO item in the menu.
To view all signups of a person, select Status menu->*Signups* or enter a person's name or email address into the Show One Person's Signups dynamic menu. You can also do this for everyone at once, via Signups per Person. However Signups per Person only lists the signups that each person "owns", whereas One Person's Signups lists them all (and indicates the unowned ones by appending via owner to each unowned one).
There are two situations where a signup is associated with multiple people:
When applicable, list-layout and grid-layout signup pages have a column, and each row has a zoom checkbox. Clicking on a zoom checkbox causes all signup info for that row to be displayed. An unzoomed schedule item's background is normally white. But if the item contains new signups, its background color is set to light green.
Similarly when signups are shown, the rules are as follows:
Fullness (i.e. n-used of n-spots) is also color coded. In the list layouts, it goes from red to orange to green as the item goes from empty to (over)full. In the grid and calendar layouts, it is simplified to black is not-full and green is (over)full.
Status is also color coded. For example in the list layout, the Status menu of an unapproved request has an orange background (and orange letters in the other layouts — because its background color is used for signup age).
When someone (or you on behalf of someone) does a signup request, the created signup appears on the signup page with a status of Pending. Eventually you need to cancel the request or approve it. Before that, you can do a tentative assignment if desired — by setting Status to Ready: directly or by doing a *Move*.
To cancel a request, click on its trash can. Since this is a final disposition of the request, it triggers a Disapproval notification message (if you set this up).
Approval of a request is a final disposition of the request. Therefore it triggers an Approval notification message (if you set this up). To approve a single request, set its status to *Approve*. To simultaneously approve all ready requests in all schedules of an event, move the mouse over the middle MORE menu and select Approve All Ready Requests. (By the way, if there is a Ready request you are not ready to approve, simply change its status back to Pending before doing the Approve All).
To approve a plain request, you usually just select *Approve*. You also have the option of doing a tentative assignment. However it will be visible to the user, unless you use the 2-phase approach described below.
To approve a category request, you must first *Move* it to one of its specific activities (i.e. a schedule item whose name includes a Location, and has the same Base Name and when-info as the category schedule item). You could then immediately *Approve* it, but the usual approach is to do all the assignments and then approve them all at once. In other words, because each unapproved request is listed under its category in the self-signup UI, you can play with your tentative schedule privately until you are satisfied all the assignments are final. Then you would do an Approve All to make them visible to your users.
It is possible the potential assignments in your schedule are too arbitrary to be implemented using category requests. If so, you can fallback to using plain requests in a 2-phase approach: