SharePoint lets you save sites as a site template so that you can configure a site the way you want, save it as a site template and then create more identical sites from the template. You can save old-fashioned 'SharePoint workflows' into site templates so that the new sites automatically have the same workflow provisioned.
Is it possible to save Flow / Power Automate within a SharePoint site template? Or is there an alternative approach to achieve the same goal, e.g. so that when a new SharePoint site is created it has a specific Flow / Power Automate set up automatically?
We have an ongoing system. In that system, we have used a custom form in SharePoint online, when a new item added to the project list using custom form one project site automatically based on a custom site template. That custom site template contains SharePoint designer workflows. Lists Templates, Web Parts, tec.
Nowadays Microsoft has been retired Sharepoint designer workflows. So, we need to migrate Sharepoint designer workflows to Power Automate. Power Automate is working fine for one site but we need to add that Power Automate with SharePoint custom site template. So, when the new site is created flows are created automatically like Sharepoint designer workflows
Can you please help me with the above scenario
Site Designs are an option for SharePoint templates. They can be a bit limited but they do allow for extensibility as they can execute a power automate flow as part of the provisioning process. The core provisioning logic here is rather simple: lists, site columns, theme application, content types, and a bit more. Pages are not part of the provisioning schema but they can always be provisioned as part of the flow process.
The nice thing about this is that the provisioning can be done all within SharePoint for kicking it off and getting the basics in without any custom service. Furthermore, if you need user input you could use SharePoint framework to add some sort of form on the provisioned site to 'finish' the provisioning process via an extension, I believe there is a Github out there that does exactly this.
Related
I'm a Sitecore beginner, working on Sitecore 8 with ASP.NET.
There is a page where an Ajax call has to be made to get data.
Created a test web service in the project which responds to the ajax call with success. This service will be a wrapper.
I understand, I have to consume one of the 3 options (in the title) inside the test service, to get the Sitecore items and do stuff.
But all 3 appear similar to me & not sure which one to go with, to achieve my task
Also,
1. Is there an advantage of one over the other.
2. ..and when to use which one.
Sitecore Services Client is the framework or namespace that both Item Service and Entity Service sit within. Item Web API is the legacy framework.
Use Item service if you want to do basic stuff with the sitecore Items as this is a prebuilt api. Entity Service allows you to create your own API using the Sitecore.Services.Client framework and give you much more power and control.
https://mikerobbins.co.uk/2015/01/06/entityservice-sitecore-service-client/
Use can also use Sitecore.Services.Client to do the routing and you write the controller. see https://mikerobbins.co.uk/2015/06/25/sitecore-service-client-servicesapicontroller/
I'm trying to build a 2013 Access web application that uses the SharePoint 2013 user list as a lookup. The SharePoint user list doesn't show up when linking to the SharePoint sites lists through add table and it doesn't work to link to /_catalogs/users/. This is relatively simple to do with SharePoint lists but I haven't been able to find any way to do it within an Access web application table.
You cannot link a web Database to a SharePoint list.
This is because the data in a web database is actually kept as a special SQL Server database in Azure. It is an entirely separate infrastructure.
You will need to create two databases if you want to do everything in Access. One for the web data and one to pull everything together.
I am very new to SharePoint development as well as SharePoint overall, so I apologize if this question seems like a no-brainer. I'm currently working on a SharePoint 2013 app and I'm wondering if it's possible to make a call out to some URL from within the SharePoint environment. Basically, I want to do this within an event receiver after some action is done to a list, and from there I want to make a call to some web service on my server to update my system. Using the REST API to poll the SharePoint server isn't a good option for this scenario since it won't scale very well.
When dealing with SharePoint 2013 apps you can access any resource using standardized APIs. In addition to REST SharePoint is offering the JS Client Object Model (CSOM).
In order to access data from another web than the current one, your app needs the permission to interact with the entire tenant.
If you're trying to query data from another host, you have to use JSONP because of the same origin policy.
if you are building an app using the "new App Model" for wiring up Remote Event Receivers it is possible to do anything, in which your app hosting framework/environment allows you to. If you are building a Classic App (Farm Solutions) you'll have access to perform operations which are allowable from the SharePoint servers directly...typically this is a lot as GAC deployed assemblies are granted full trust.
depending on what you are trying to do and what kind of resources you app will consume. I'd consider moving the dependancies away from SharePoint and building using the new App Model versus the older farm solutions. As you sound like you are starting in SharePoint, this gives you an opportunity to learn the new ways of doing development for SharePoint.
Lastly, you might consider building a workflow. Not sure what kind of app you are building but the new workflow capabilities include actions which can make RESTful calls. Potentially making your application a "no code" solution. Again it all really depends.
What is the difference between Sitecore's core, master, and web databases?
Master: Contains all versions of all items. This is the database that content authors interact with, and is the default database used by the Sitecore Content Ediitor.
Web: This contains only the current versions of items. This is the database that supports the live website.
Core: This database has two purposes:
It contains definitions for the Sitecore user interface (Content Editor, Page Editor, etc.). This is where you would go to add, for example, a new Right-click option to the Content Editor or a new ribbon button to the Page Editor.
It contains the ASP.NET membership tables that drive authentication and security.
I recommend you look at the Launch Sitecore site to understand more about the CMS.
From the page on Sitecore Architecture:
Master
The Master database is the authoring database - it contains all versions of any content or assets.
Core
The Core database is all Sitecore settings, as well as the tables containing the .Net membership provider (i.e. users/roles contained in the Sitecore repository)
Web
The Web database is only the latest published version, and the content that is driving the live web site. Therefore it is a subset of the master database, optimised for size and speed. When content is published, or goes through the publishing task of a workflow, the latest content version is copied from the master to web database.
Of course, in an Enterprise deployment, you may have multiple Sitecore instances, which may share DBs (or not)
Some great answers here but it's worth a clear note that the Web database is the default publishing target and is not set in stone. You can rename it to whatever you wish as well as have multiple publishing targets similar to 'Web'.
e.g. We have a Sitecore instance with two websites (website and intranet), thusly the Master database contains all the items for both sites. For publishing we have two targets 'Website' and 'Intranet' that are hosted by different SQL servers.
Ultimately our connections include: Core; Master; Website; Intranet (the latter two being copies of the original 'Web' database of course)
So here is the scenario:
I have a MOSS 2007 box and I want my clients to be able to access a SharePoint site via the internet. I am told that I will be using an IPA and AD for authentication. However I have a DB outside of SharePoint that holds various business data and I want to use Web Services to access the data, manipulate it, and send it back to SharePoint via web parts.
The issue is that, from what I understand, I am going to have to authenticate the AD user every time a request to the Web Service happens. Obviously I dont want to do this every time because they have already authenticated to get onto the site, however I do want each call to have some form of security so its not open calls to my db. I do plan on having other applications access this service outside of SharePoint, so I dont want to have to reinstall the service for each application or even again.
Has anyone had to perform this task or something similar or do you have any suggestions on how to do this?
Thank you in advance and happy coding!
Why not just deploy the webservice to Sharepoint using a Sharepoint solution and a Feature.
That way it will be running under the sharepoint app pool and all authentication is done by sp.
Edit:
Seeing that SharePoint should not be in "control" (as stated in the comment), you should create the webservice, and run the application it's under in as using Windows Authentication. IMHO you should create a WCF Service. The, using the information found in this article you make the Service authenticate users against the AD usergroups they are in. see the "Security: Authentication" section of the article.
Then in Visual Studio you create a webpart and add a service reference to the project, pointing to your newly created Service. Have the webpart perform the needed logic (i.e. display data etc.)
Deploy the webpart to SharePoint using a SharePoint solution (.wsp files, created with WSPBuilder). Google for SharePoint + wspbuilder + tutorials. The solution should contain 1 feature to deploy the webpart. WSPBuilder integrates with VS and allows for the creation of WSPBuilde project. add a webpart feature item to the project (it will create the xml (deployment related) and code file for the webpart.