Abstract: A computing system record security architecture comprises, in one example, a record generation component configured to receive a record generation request that includes a set of attributes and to generate a record in a computing system based on the record generation request, wherein the record includes the set of attributes and an owner property that identifies a first user as an owner of the record. The architecture comprises a record security component configured to receive a record modification request that requests a modification to the record, to analyze an identifier in the record modification request that identifies a second user as a sender of the record modification request, and to process the record modification request based on an analysis of the identifier in the record modification request relative to the owner property of the record.

Abstract: An account aggregation service receives account credentials for a first network service account and associates the credentials with a list of network service accounts. Access tokens for other network service accounts can also be obtained and stored with the list of accounts. The account aggregation service can utilize the access tokens to access the other network services on behalf of a user. The account aggregation service can also enable the configuration of a second or subsequent computing device by receiving the credentials for the first network service account. The account aggregation service can then utilize the account credentials to retrieve the associated list of accounts. The list of accounts can then be provided to the second or subsequent computing device. The second or subsequent computing device can access the other network service accounts via the account aggregation service.

Abstract: A computing system record security architecture comprises, in one example, a record generation component configured to receive a record generation request that includes a set of attributes and to generate a record in a computing system based on the record generation request, wherein the record includes the set of attributes and an owner property that identifies a first user as an owner of the record. The architecture comprises a record security component configured to receive a record modification request that requests a modification to the record, to analyze an identifier in the record modification request that identifies a second user as a sender of the record modification request, and to process the record modification request based on an analysis of the identifier in the record modification request relative to the owner property of the record.

Abstract: An application provides a “working elsewhere” status for users working at a location other than their regular work location and still available for meetings, communication sessions, etc. The application determines a user location being other than regular work location and the user still being available through user selection, information from user associated application(s), and/or from a presence notification. The application adjusts the user status to a working elsewhere status and makes the new status available to other applications such as calendaring, communication applications, presence service(s), and comparable ones. Meetings may be scheduled, communication sessions facilitated if the working elsewhere status is sufficient/acceptable for other users.

Abstract: An application retrieves a published calendar from an online calendar application. The application formats the published calendar according to user status states such as “free” or “busy.” The application can also alternatively assign user status information from the published calendar to users status state levels such as “free,” “tentative,” “out of office,” “busy,” and “remotely available.” The application matches calendar owner information to a contact from a contact list of the application in order to link the formatted calendar to the contact. The application presents the linked calendar for scheduling.

Abstract: An application provides a “working elsewhere” status for users working at a location other than their regular work location and still available for meetings, communication sessions, etc. The application determines a user location being other than regular work location and the user still being available through user selection, information from user associated application(s), and/or from a presence notification. The application adjusts the user status to a working elsewhere status and makes the new status available to other applications such as calendaring, communication applications, presence service(s), and comparable ones. Meetings may be scheduled, communication sessions facilitated if the working elsewhere status is sufficient/acceptable for other users.

Abstract: An application retrieves a published calendar from an online calendar application. The application formats the published calendar according to user status states such as “free” or “busy.” The application can also alternatively assign user status information from the published calendar to users status state levels such as “free,” “tentative,” “out of office,” “busy,” and “remotely available.” The application matches calendar owner information to a contact from a contact list of the application in order to link the formatted calendar to the contact.